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1. INTRODUCTION 


In January 1990, the National Aeronautics and Space 
Administration (NASA) renewed its grant with Center for Systems 
Engineering and Computing (CSEC) , Howard University. This new 
Grant [No.: NAG 5 995] has as its primary focus 'space network (SN) 
modeling and evaluation'. A secondary objective is to develop a 
research and training capability in systems engineering at Howard 
University which directly relates to NASA's needs. 

This document reports on the activities conducted and the 
results achieved by CSEC, under the referenced grant, during the 
period February 1, 1991 through July 31, 1991. 


2. PROJECT OBJECTIVES AND PLANS 


2.1 SHORT-TERM PLANS FOR SPACE NETWORK MODELING AND EVALUATION 

A research plan has been developed for space network modeling 
and evaluation. This plan spans the period January 1990 through 
December 1992 and includes the following tasks: 

• Network Modeling 

Developing Measures and Metrics for the SN 
Modeling of the Network Control Center (NCC) 

Using Knowledge Acquired form the NCC to Model the 
SNC 

Modeling the SN 

• Space Network Resource Scheduling. 


2.1.1 TASK ONE: NETWORK MODELING 

A. Technical Objective - The objective of this task is to 
investigate the overall behavior of the Space Network (SN) ground 
segments, subjected to the introduction of a new network element, 
through simulation and modeling. 

The result of such a modeling effort will provide a means by 
which emerging systems engineering technologies potentially 
applicable to the SN ground segments could be evaluated and 
assessed. 

B. Background - At present, there exists no established mechanism 
to evaluate emerging systems engineering technologies or concepts 
for the NCC, the White Sands Ground Terminal (WSGT) , and the NASA 
Ground Terminal (NGT) . During the next decade, all of these ground 
elements of the SN will undergo significant changes in order to 
improve user services. These improvements will be accomplished 
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using new and emerging technologies. Methods and techniques are 
clearly needed to evaluate and assess candidate technologies. 
Future systems, such as the Advanced Tracking and Data Relay 
Satellite (ATDRS) , the Second TDRSS Ground Terminal (STGT) , and the 
Space Network Center (SNC) will benefit from this research. 

C. Approach - The primary emphasis on the systematic approach to 
network technology assessment is the use of quantitative 
techniques. First, a set of measures/metrics, which will permit 
one to assess the state of a network with regard to its 
performance, reliability, service capacity, configuration 
optimality, and other characteristics must be identified and 
described. This set must then be carefully analyzed to ensure that 
the metrics are not coupled and are independent of each other. 
Next, using the defined metrics, the SN ground segment will be 
modeled to obtain the "baseline" data. 

This modeling will be carried out using a comprehensive 
simulation tool such as Data Systems Dynamic Simulator (DSDS) and 
Optimized Network Engineering Tools (OPNET) . The developed model 
will be refined to increase the simulation fidelity and calibrate 
using "observed" data. Candidate technologies, such as the new 
INTEL 80486 processors for a new data formatter or the "Black Box" 
alternative to fulfill the STGT capabilities at the NCC, could be 
assessed and evaluated using this model. The results from such 
assessments will be invaluable to the decision-making process of 
introducing new features into the SN. With two sets of data 
quantitatively indicating the "before— and— after" effects of 
introducing the new technology into the system, a sound technical 
decision can then be made whether the technology under study should 
ultimately be implemented as an element of the SN. 

D* Milestone Sc hedule - This task was initiated in May 1990, with 
personnel from Howard University and Virginia Polytechnic Institute 
(VPI) . The definition of the initial set of metrics has been 
completed. The SN modeling effort was also initiated in May 1990, 
with a completion date scheduled for December 1992. Technology 
assessment phase will begin upon completion of the modeling effort 
i.e. in January 1993. ' 


2.1.2 TASK TWO: SN RESOURCE SCHEDULING 

A* Technical — Objective - The objective of this task is to 
investigate the SN scheduling problem with the goal of reducing the 
scheduling requirements of the networks. 

B : . Background - The current SN is constrained by bandwidth 
limitation. SN resource scheduling functions currently reside in 
the NCC, and are clearly separated into forecast and active 
scheduling periods. Under this task, recently proposed scheduling 
concepts and existing scheduling systems (military, airlines, other 
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NASA, telephone companies, and other industry, etc.) will be 
evaluated to determine potential applicability to the SN 
scheduling problem. In addition, the basic premise of separating 
scheduling functions into forecast and active periods will be re- 
examined from the database design view point. 

C. Approach - The research on scheduling will be conducted in 
five steps, as follows: 

(1) The first step is to identify and examine existing scheduling 
systems and the associated problems that they address. 
Results of this step will be evaluated to identify concepts, 
technigues, and algorithms that may be relevant to the SN 
scheduling problem. 

(2) The second step is to scrutinize the existing problem 
definition and the corresponding functional and technical 
requirements of the SN scheduling. The schedulable TDRSS 
resources include: the links, bandwidth, and antennas for both 
forward and return links for multiple access (MA) , S-band 
single access (SSA) , and K-band single access (KSA) services 
as well as tracking service using one-way doppler and MA and 
SA two-way range and doppler. If required, modifications will 
be made to the problem definition and the requirements, in 
order to fully address the SN scheduling needs of the 90' s and 
beyond . 

(3) The third step will be to investigate demand/assignment as an 
alternative approach to resource scheduling. This approach is 
somewhat analogous to that used by telephone companies. 
Included in this area is the possible use of packetized 
messages wherein a message header is used to route traffic. 
Of particular interest is the Consultative Committee for Space 
Date Systems (CCSDS) recommendation for space data system 
standards. A primary CCSDS Path service objective is the 
optimization of the utilization of space channel bandwidth. 
The basic unit of transmission for CCSDS Path service data is 
the CCSDS packet. 

(4) The fourth step is to examine all the proposed techniques in 
the area of generic scheduling. These techniques will include 
the use of Network Planning and Analysis System (NPAS) as a 
prescheduler; the Resource Management/Decision Support System 
(RM/DSS) from Information Sciences, Inc.; Jet Propulsion 
Laboratory's (JPL's) RALPH System; and Goddard Space Flight 
Center (GSFC) Code 520's ROSE algorithm. 

(5) The fifth step is to develop, if feasible, an overall 
strategy, procedure, and algorithms for the SN resource 
scheduling which will encompass both generic and specific 
scheduling for forecast and active periods. Using the SN 
model developed under Task 1, the strategy, procedure, and 
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algorithms can then be tested for their performance and 
accuracy in a simulated environment. 

D. Milestone Schedule - This task was started in May 1990. Steps 
One and Two which are interrelated were scheduled to be completed 
by March 1991. Step Three was expected to be completed by December 
1991. Steps Four and Five are scheduled to be completed by 
December 1992 and December 1993, respectively. 


2.2 SCOPE OP ACTIVITIES PLANNED FOR THE REPORTING PERIOD 

The activities planned for this reporting period included four 
subtasks as follows: 

• Network Modeling 

(1) Updating the measures and metrics for the NCC; 

(2) Upgrading the preliminary models of the NCC; 

(3) Transferring the knowledge and experience gained in 

modeling the NCC to developing preliminary 

performance models of the SNC 

• Space Network Resource Scheduling 

(4) Researching resource scheduling techniques. 

The project is organized with Howard University as the prime 
grantee and VPI as the subgrantee. Howard has primary 
responsibility for Subtasks Two: developing preliminary models of 
the NCC and Subtask Three: transferring the knowledge and 

experience gained in modeling the NCC to developing preliminary 
performance models of the SNC; VPI has primary responsibility for 
Subtask Four: researching resource scheduling techniques; and 

Howard and VPI share responsibility for Subtask One: defining an 
initial set of measures and metrics for the NCC. 


3. DETAILED ACTIVITIES CONDUCTED DURING THE REPORTING 
PERIOD [FEBRUARY 1 THROUGH JULY 31, 1991] 


3.1 PROJECT PLANNING AND REVIEW 

• Conducted weekly planning and working meetings with the 

Technical Officer at the ND. A copy of the milestone chart is 
presented in Appendix A; 

• Conducted weekly planning and technical meetings of the 

technical staff at Howard; 

• Conducted periodic planning and technical meetings and 
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discussions with VPI; and 

• Conducted periodic meetings with the Technical Officer and 
other managers of the ND. 

3.2 MEASURES AMD METRICS 

. Updated the measures and metrics selected for the NCC. A 
proposed set of measures is included as Appendix B. 

3 . 3 MODELING 

• Conducted extensive reviews of the technical literature to 
clearly understand the operations and information flow 
patterns of the NCC; 

• Conducted discussions and meetings with technical personnel 
within ND in an attempt to characterize the NCC; 

• Updated separate message manuals for internal and external 
messages of the NCC. Copies of these manuals are included as 
Appendix C; 

• Upgraded the preliminary model of the NCC using OPNET. 
Specific tasks included: 

(1) Specifying the level of detail of the model — determining 
which specific processors will be modeled; 

(2) Designing network base models [ Ethernet/TCP/ IP ] ; 

(3) Developing node and process models for Ethernet media 
access and TCP/IP; 

(4) Testing base models; 

(5) Evaluating runtime performance of base models; 

(6) Reducing the complexity of the base models to improve 
runtime; 

(7) Designing the top level models, using the base models; 

(8) Characterizing the workload in terms of message 
generation, message processing and network services; 

(9) Developing message format; 

(10) Developing message generation and message processing 
algorithms and models; 
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(11) Testing message generation/processing models; 

(12) Testing complete model with test data; and 

(13) Testing model with actual data. 


pHtonn^ot 1 ' the P N n eSen \ ati0 \?? the pr °3 ect activities to 
LcluSSd as Appendix D; ” ° Utll " e ° f the Potation is 


Provided support to the staff of Code 532 in connection with 
technical review of this project at the division level; 


Compiled information on the NCC 
effort; and 


in support of the modeling 


Compiled information on the SN in 
activities. 


support of future modeling 


3.4 APPLICATION TO 8NC 

rsi P g r „ 0 l e f Ct the an s a N g c er to stay up 

3.5 RESOURCE SCHEDULING TECHNIQUES 

Conducted a preliminary review of the literatus nn 
scheduling techniques. Papers developed by VPlTn tlat In 
are presented in Appendix E. Y that re 9 ard 


3.6 ACHIEVEMENT OP ANCILLARY OBJECTIVES 


Ind S one°i? C VPI? Vided Partial SUPP ° rt t0 tM at Howard 

H o wa r d "a nd ^ n e W g r adu ate* Zt ixten 1 t° at at 
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APPENDIX Bl MEASURES AND METRICS 



1 . 


1 . 


MEASURES OP PERFORMANCE FOR THE NETWORK CONTROL CENTER 

T ^ e suggested scheme for measuring the performance of the 
Network Control Center (NCC) incorporates two types ™ indicators? 

Indicators of the quality of t he product/servi cp i. e . the 
quality of the schedules produced by the NCC and/or the 
< 3 uallt y' the service to the users, and 

Indicators of the NCC's ope rational effect iven^« g i. e . 

£L^! eCtlV : n *? S ln Processing requests, developing 
schedules, and disseminating results 


1.1 


INDICATORS OF THE QUALITY OF THE PRODUCT/SERVICE 


fh . following are suggested as indicators of the quality of 

the product/ service provided by the NCC: 4 ot 

Availability of each schedulable resource 
Utilization of the available Space Network (SN) resources 
Percentage of all requests satisfied -- 

Percentage of requests for SN resources satisfied 
Percentage of emergency requests accepted 

S^N n ?L™ requested changes to the users 


1.2 


INDICATORS OF THE NCC'S OPERATIONAL EFFECTIVENESS 


that ^t S m n=^ ha3 established specific quantifiable requirements 
that it must achieve in providing services to SN users th™ 
requirements have been analyzed as a basis for selecting tut 
following indicators of the operational effectiveness of the 9 NCC: 


1 . 2.1 


Utilization of NCC's Communications Capacity 

Average communications capacity utilized bv 
incoming messages (single user) . 

Percentage of times that incoming messages (single 
user) exceeds 56 kilobits per second. * 9 

Average communications capacity utilized bv 

incoming messages multiple user. 

timeS that incoming messages 
(multiple user) exceeds 112 kilobits per second. 

Average communications capacity utilized by 

outgoing messages (single user) . y 

ncf^f ntage time ? that outgoing messages (single 
ser) exceeds 56 kilobits per second. 

Average communications capacity utilized by 

outgoing messages multiple user. 

Percentage of times that outgoing messages 


(multiple user) 


exceeds 112 kilobits per second. 


1 . 2.2 


Acknowledgements and Response Time 


Percentage of times the NCC fails to send response 
to originator of specific schedule request wit 
one (1) minute of receipt of request. 

Percentage of times the NCC fails to schedule an 
eventor^ identify all conflicting events within 25 
comnHs of receipt of a request. 


Percentage of tiroes the 
substitute event exceeds (2) 


NCC’s search 
minutes . 


for a 


1.2.3 


Specific Requests Processing 

Average Processing Time £or specific Schedule 
Requests (Seconds) . 

Percentage of time that a single event: add, 
delete or cancel request without NCC operator 
intervention exceeds 25 Seconds. 

Percentage of time that a replace re ^® st t ^ h °5 q 
NCC operation intervention takes more than 

seconds . 

. percentage of time that a multiple time shift 

request without NCC operation intervention excee 
50 q seconds times the number of events processed. 

Pprcentaae of time that a multiple delete or a 
multiolJ 9 cancel request without NCC operation 
intervention exceeds 25 seconds times the number of 
events processed. 

. Percentage of time the search for an event that is 
affected 9 by a change in predicted spacecraft 
visibility exceeds five (5) seconds. 


Percentage of times a reconf T^T dpf' 
transmitted to the SN element and the SDPF, or a 
rejectionmessage to a valid configuration request 
takes more than five (5) seconds. 


Percentage 
performance 
seconds from 
FIMS message. 


of times NCC's transmittal of 
data to a users exceeds eight (8) 
the time it is received in an ODM or 



1 . 2.4 


Other Operational Effectiveness Measures 

The following are suggested as indicators of the 
operational effectiveness of the NCC: 

Overall Average processing 
. Average processing time at CCS all 

Average processing time at ITS— all requests 
. Average processing time at SPS-all requests 

. overall Average delay — all requests 
Average delay at CCS— all requests 
. Average delay at ITS — all requests 

. Average delay at SPS — all requests 

. overall Average processing time— all Responses 

. overall Average delay — all Responses 

Overall Average Utilization— all Subsystems (CCS, 
ITS, SPS) _ 

• Average utilization CCS 

• Average utilization ITS 

• Average utilization— —SPS 

Average Time to compose the active schedule 
. The average number of requests process per unit of 

time for emergency requests 


LAN Utilization, etc. 
Others 



APPENDIX C l MESSAGE MANUALS 


1 . 


INTRODUCTION 


of the National Aeronautics and Space 
The NCC is an element of the Data Network (STDN) . The 

Administration (NASA) Spacefligh 9 Relay satellite system 

STDN is a network that uses a Tracking fn^Data^^y spaceora£t The 

(TDRSS) as the primary a relay satellite system and several ground 
new STDN | TD N grounl stations are linked to the NCC at 

stations* All tco.vc\ which serves as the central control 

Goddard S P a « c ®. Th e NC C is responsible for network scheduling, 

al^isition and fracking^Iupport, aata guality assurance, performance 
monitoring, overall coordination of STDN. 

This document will serve to ^he^NCC "a^hl 

gro^l stations^ “eve,? g^und stations make up the system, they are. 


1 ) 

2 ) 

3) 

4) 

5) 

6 ) 
7) 


Flight Dynamics Facility (FDF) 

Johnson Space Center (JSC) 

NASA Communication Network (NASCOM) 

NASA Ground Terminal (NGT) 

Payload Operations Control Center (POCC) 
Sensor Data Processing Facility (SDPF) 
White Sands round Terminal (WSGT) 


serve as supplementary and/or backup communication capability. 


2 . BACKGROUND 


High Speed Messages 

The NCCDS has the capability of receiving and ^ 

automatically and in rea P° ‘Vij ''non-seclire coimnunications circuits. All 
data messages via secured a c-t-andard NASCOM 4800 -bit block 

iTSS-T^nterface Standard for Digital Data 
Transmission (NISDDT) . 


Message Handling Requirements 

NCC requirements for handling electronic messages are as 
follows: 

1. Acknowledgement 

As specified in the applicable interface control 



documentation, the NCCDS shall determine whether incoming 
messages have been received correctly or in error. For 
correctly received messages that indicate that an 
acknowledgement is requested , the NCCDS shall transmit 
an acknowledgement with in 2 seconds of receipt. 
Messages received in error shall not be acknowledged. 
The NCCDS shall check each correctly received message to 
determine if is a retransmitted message. If so the NCCDS 
shall determine if a previous transmission of the same 
message has been correctly received. If so the 
retransmitted message will be acknowledged but shall not 
be otherwise processed. 

2. Validation Checking 

As specified in the preceding sections, the NCCDS will 
have the capability to detect invalid messages, alert 
the operator, and selectively log the message. 

3. Message Routing. The NCCDS shall: 

Automatically route correctly received incoming messages 
to the appropriate functions/positions. When a 
destination function or position is temporarily 
unavailable, the NCCDS shall retain correctly received 
incoming messages for routing to that function or 
position at a later time. The NCCDS shall be capable of 
retaining each such message for at least two hours. 
Within 5 seconds of the System Supervisor's (SS) request, 
the NCCDS shall present a summary of such retained 
messages. Retained messages shall be summarized by 
source, type, and class. The NCCDS shall provide the SS 
with capability to selectively purge such retained 
messages by specifying one or more of source, type, 
class, and appropriate time related parameters (e.g 
requested event start time in a specific schedule add 
request) . Send and receive all high-speed messages to 
and from unsecured facilities through the RAP subsystem 
that is currently prime. 

For each secured facility having a high-speed message 
interface with the NCC, send and receive all high-speed 
messages to and from that facility using the protected 
circuit dedicated to that interface. 

4 . Message Metering 

The NCCDS shall be capable of metering the transmission 
of high speed message blocks so that the transmission 
rate to any destination does not exceed the maximum rate 
specified for that destination. The maximum transmission 
rate for each destination will be specified in terms of 
a minimum time interval between the initiation of the 
transmission of two Jsijccessive high speed message blocks 



to that destination For all messages «~f t ^mUs“n 
acknowledgements the Nc ^ s J ”“ a c 9 ified minimum time 
algorithm shall “ initiation o£ message 

intervals to control ... nation Stand-alone 

transmissions to each transmitted as soon as 

acknowledgement messages may be transmitted a 

generated. 

Message Logging. 

rrho wrens shall be capable of controlling the logging and 

requirements are contained in section 8 ST 
Retransmission 

. . • j the aDDlicable interface control 

documentation, the NCCDS shall be "il 

?f-Sd” e F^ss\Vs1 

Tf fr a retransmission. If acknowledgement of the first 
It IS a retransiuiB r-ereived within 5 seconds of 

retransmission of a ” essage th ^ S N ^ s % se nd" act" o n 

lit™? to' tSf SS“onre£' operator responsible for the 
acknowledged message and to the SS. 


Acknowledgement Reporting 


In all instances where the transmission of an individual 
hiah-speed message is initiated by, or requested by an 
ncc operator, the NCCDS shall, within 5 seconds of 
receipt of the acknowledgement of the transmission, 
present an information alert to the originating console 

operator. 

T 4 -K^es.m instances where the transmission of a stream, 
sequence, or batch of high-speed messages is originate 

sequence, fed & NCC console operator, the NCCDS 

Sill report the receipt of acknowledgements as specif le 
elsewhere in this document. 



3 . 


EXTERNAL MESSAGES 


3 . 1 EXTERNAL MESSAGES BETWEEN NCC AND FDF 
The FDF provides 

missions from early planning f ving validating (in real time), 

The FDF is responsible f' or receiving, Base d on tracking data 

calibrating, and archiving t spaclcraft/payload NASA transponder 

received, the FDF win pro provides orbit data used in 

frequency history to each user t °" and scheduling 

S- 3 Efe s s p £3 

Sansponde^ystSn (BTRS^The^CC revest additional data when needed. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


IMPROVED 

FDF 

03/09 

1 

OPM 


INTERRANGE VECTORS 
DESTINATION 

FREQUENCY 


(IIRV) 


- INFLIGHT 
NCC 


Details the forces which perturb the spacecraft's 
orbit. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


USER ORBIT 
FDF 
03/09 
1 


PREDICTION FORCE MODEL 
DESTINATION : 

FREQUENCY : 


NCC 


GROUP 


This message provides the capability to define a 
subset of the user orbit prediction force model by 
specifying which components of the force model are 

to be used. 


DESCRIPTION 



USER PREDICTION 


NCC 


message name 

ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


FDF 

03/09 

1 


destination 


FREQUENCY 


OPM 

Details the forces which perturb the 
orbit. 


spacecraft's 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


IMPROVED 

FDF 

03/10 

1 

OPM 


interrange vectors 

DESTINATION 

FREQUENCY 


(IIRV) 


- NOMINAL 
NCC 


Provides spacecraft position and velocity vectors 
to used in scheduling. 


MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 


IMPROVED 

FDF 

03/10 

1 


INTERRANGE VECTOR MESSAGE 
DESTINATION 

FREQUENCY : 


(IIRV) 

NCC 


i IIRV contains the spacecraft position and 
locity vectors tor the given epoch time the llRV 
so contains information indicating whether it is 
nominal or real-time message. 


GROUP 

DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


IMPROVED INTERRANGE VECTORS (IIRV) - INFLIGHT 
PDF DESTINATION : NCC 

03/15 

1 FREQUENCY : 

OPM 

Provides spacecraft position and vectors 
to be used in scheduling. 


ACKNOWLEDGEMENT 

FDF DESTINATION : NCC 

03/60 

1 FREQUENCY : 


Sent upon the reception of a complete message 
requiring an acknowledgement. 


COMMUNICATION TEST 

FDF DESTINATION : NCC 

91/03 

1 FREQUENCY : 


Used to verify the existence of an operational 
communication link. 



DESTINATION 


FDF 


MESSAGE NAME : 

ORIGINATION : 

TYPE/CLASS : 

MESSAGE LENGTH : 
GROUP : 

DESCRIPTION 

message name : 

ORIGINATION : 

TYPE/CLASS : 

MESSAGE LENGTH : 
GROUP : 

description 

message name 

ORIGINATION 

type/class 
message length 
group 

DESCRIPTION 


acknowle dgement 


NCC 


03/14 

1 


FREQUENCY 


Sent upon reception of 

an acknowledgement. 


a complete message requiring 


COMMUNICATION TEST 

DESTINATION 

NCC 


91/03 

1 


frequency 


FDF 


Used to verify the 

communication In- 


existence 


of 


an operational 


acquisition 

NCC 

92/63 

1 


FAILURE NOTIFICATION 

destination 

frequency 


FDF 


• j a rGtuirn service 
Hhen an attempt to P ro ''“* Data Message (SHO) 
requested in a scheduling order Data ^ ire 

IIS not occur due to. ^^^uition Failure 

the user ^f^lfSom the ><« to FDF. 
Notification is sent rro 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


message name 

ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 

MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


USER SCHEDULE 

NCC 

94/06 


transmission summary 
destination : 


frequency 


FDF 


j v» -i-ho NCC to the user 

This is transmitted by t N ^ User Schedule 

immediately following of the weekly schedule or 
Message in _a transmission °tJ* ansmLsslon request. 


acquisition 

NCC 

97/01 


DATA REQUEST 

destination 


frequency 


FDF 


This message 
additional or 


s used by the NCC to 
: ■: arrniisition data . 


request 


TRACKING 

NCC 

97/10 

1 


and data schedule 
destination 

FREQUENCY 


FDF 


GROUP 

description 


Schedule 


for BTRS calibrations. 



MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


LAUNCH DELAY 
NCC 
97/11 
1 


NOTIFICATION 

DESTINATION 

FREQUENCY 


FDF 


Will provide the FDF ^,>r SUpp ?^ ed launch - the NCC 
launch date/ time The^o?i "? tl £ acatio " of the new 
date/time will be tonL SL 10 " ° f new launch 

notification itssage fo™et d ln laUnCh del ^ 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


EMERGENCY ROUTINE VERIFICATION 

NCC DESTINATION 

98/15 

1 FREQUENCY 


SERVICE RECOMMEND. 
: FDF 


Emeir^ncy Routine Verification Service 

operator^control r6 to fr °" the KCC ' 

schedule event in order ^hat a “ ser . to relinquish a 
be faulty nay be tested by" the SUS P actad to 



message name 

ORIGINATION 

type/class 

MESSAGE LENGTH 


SCHEDULE RESULT MESSAGE 


NCC 

99/02 

1 


destination 

frequency 


FDF 


GROUP 

description 


rh e schedule Result ns M e eS t oT scSel^e Revest*!® The 

to the FDF in response to a sene ^ ^ NCC 

tiessage describes dele te replace or cancel. 

rhe C Nee' wl 1° £ transmit a message with appropriate 
code. 



3 . 1 EXTERNAL MESSAGES BETWEEN NCC AND JSC 

.T* 1 ? JSC provides command control and systems monii-orinrf 

STS at> t h ^ mcc f -° r thS ?P a J e Transportation System (STS) . To support the 
MAQAr.M h required to interface with NCC to schedule the STDN 

NASCOM and Department of Defense (DOD) resources. The NCC will receive 

request^^f^CMR^sl^th^t^r a " d * r ° u " d USE 

network. that sults ln certain reconfiguration of the space 

receive performance data from the TDRSS and ctct 
provide this information to the MCC once every 5 sjconds in the 

routed" to ^ V°T ent - At the MCC, the ^erfo^ance data will be 
routed to the network communications interface cominon (UCTC\ whipK 

?Mf°dTte to r th in Y al f dation checks on the network Serf and rSs 
data to the mission operations computer (MOC) . The MOC intemret^ 

certain 13 validation "if ^ ^ -- 

?he rre G S d s in „ 9 ii g r^ d a T^STST !° the “• “ PtoSln^l 

invoked, and & VsSsS ^’SsS^Sd"^ tK 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


FORWARD LINK EIRP RECONFIGURATION 


JSC 


DESTINATION 


NCC 


1 

GCMR 


FREQUENCY 


Provides the JSC with the capability to 
reconfigure the SSA and KSA Forward EIRP 
normal and high power mode on the TDRS. 


between 



message name 

ORIGINATION 
TYPE/ CLASS 

message LENGTH 
group 

DESCRIPTION 

message name 

ORIGINATION 
TYPE/CLASS 

message LENGTH : 

group 

DESCRIPTION 

message name 

ORIGINATION 
TYPE/ CLASS 

message LENGTH 
group 

description 


forward 

JSC 


link sweep 

destination 


NCC 


frequency 

1 


fhe JSC With the capability to 
Provides the JSt » 

Forward Link Sweep. 


request 


SPECIFIC 

JSC 


SCHEDULE REQUEST MESSAGE 
DESTINATION 


NCC 


FREQUENCY 

1 


This is used to 

network resources 


add or 


delete 


shuttle event for 


. DOPPLER 
JSC 


COMPENSATION INHIBIT REQUEST 
DESTINATION 


FREQUENCY 


GCM 

Provides the 
forward link 
link. 


TSC with the capability 
doppler compensation 


to inhibit 
a specific 



MESSAGE NAME : 

KSA RETURN 

LINK 

ORIGINATION : 

JSC 

DESTINATION ; Ncc 

TYPE/CLASS : 


MESSAGE LENGTH : 

1 

FREQUENCY : 

GROUP . 



DESCRIPTION : 

Provides the JSC with the capability to 
reconfigure the KSA Return Link. 7 

MESSAGE NAME : 

SSA RETURN LINK 

ORIGINATION : 

JSC 

DESTINATION : Ncc 

TYPE/CLASS 


MESSAGE LENGTH : 

1 

frequency 

GROUP . 

GCMR 


DESCRIPTION : 

Provides the 
reconfigure 

nf SC oJl ith the ca Pability to 
the SSA Return Link. 

MESSAGE NAME 

SSA FORWARD 


ORIGINATION 

JSC 

DESTINATION • NCC 

TYPE/CLASS : 


MESSAGE LENGTH : 

1 

FREQUENCY : 

GROUP 

GCMR 


DESCRIPTION : 

thG JSC with the capability to 
reconfigure the SSA Forward Link. Y * 



KSA FORWARD LINK 

-rc r DESTINATION 


NCC 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


x FREQUENCY : 

GCMR 

Provides the JSC capability to reconfigure the KSA 
Forward Link. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


EXPANDED USER FREQUENCY UNCERTAINTY REQUEST 


JSC 


DESTINATION 


NCC 


FREQUENCY 


3CMR 

Provides the JSC with the capability of expanding 
the frequency uncertainty of the reference 
return event. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


STATUS MESSAGE 


JSC 


DESTINATION 


NCC 


FREQUENCY 


n receipt of GCM the JSC will send an operation 
lanning message to the NCC indicating either that 
he GCM was rejected or accepted. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


reconfiguration request 


JSC 


destination 


NCC 


FREQUENCY 


GCMR 


These are four messages 
capability to request a 
specified services. 


providing the JSC with the 

reconfiguration to the 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


REACQUISITION REQUEST 

JSC DESTINATION 

98/03 
1 

GCMR 


NCC 


FREQUENCY 


Provides the JSC with the capability to 
reacquisition of service. 


request 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


SSA SHUTTLE RETURN SERVICE DQM 


NCC 


DESTINATION 


JSC 


•L FREQUENCY : 

UPD 

Message continuously monitors the quality of data 
of return data and clock signals. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


KSA SHUTTLE RETURN SERVICE 

NCC DESTINATION : JSC 

1 FREQUENCY : 

UPD 

This packet contains the operations data for KSA 
shuttle return services. 


KSA SHUTTLE RETURN SERVICE DQM 

NCC DESTINATION : JSC 

1 FREQUENCY 

UPD 

This packet contains DQM data for KSA shuttle 
return service. 


SSA SHUTTLE RETURN SERVICE MESSAGE 
NCC DESTINATION : JSC 

1 FREQUENCY : 

UPD 

This service contains the operation data for SSA 
Shuttle return service. 


DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


KU - BAND ACCESS FORWARD SERVICE 


NCC 


DESTINATION 


JSC 


FREQUENCY 


UPD 

This message contains the operation data for KU 
-Band access Service. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


S-BAND SINGLE ACCESS FORWARD SERVICE 


NCC 


DESTINATION : JSC 


1 FREQUENCY : 

UPD 

This packet contains the operation data for a 
s-band single access forward service. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SINGLE ACCESS 


NCC 


DESTINATION 


JSC 


! FREQUENCY : 

UPD 

This is used if the user has an active single 
access service. 



GROUP 

description 


MESSAGE NAME 


GCM STATUS 


ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NCC 

98/01 

1 


DESTINATION : JSC 


FREQUENCY 


GCM 

These messages indicates acceptance or reason for 
rejection of user transmitted GCMR. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


DISPOSITION MESSAGE 

N CC DESTINATION 

98/02 

1 FREQUENCY 

GCM 


JSC 


Indication to the TSC of whether or not an 
acknowledgement was received from the SN . 


3.3 EXTERNAL MESSAGES BETWEEN NCC AND NASCOM 

NASCOM provides common carrier communication services among the 
TDRSS ground segment (including NGT), Johnson Space Center (JSC) , an 
GSFC using a wideband data system interfaced through a 
Multiplexer/Demultiplexer (MDM) system and a Statistical Multiplexer 
(SM) system. As part of NASCOM, MDM and SM units are located at the 
TDRSS ground segment, JSC, and GSFC. The MDM baseline composite 
transmission service will be 6 mb/sec from NGT and 2.5 mb /sec to the 
TDRSS ground segment. Spacecraft data with rates up to 2 mb/sec will 
normally be transmitted from the TDRSS ground segment by MDM. 
Spacecraft telemetry data with higher rates will be transmitted by the 
SM which is capable of transmitting up to four channels of data 
simultaneously with a maximum composite data rate of 48 mb/ sec. Data 

from TDRSS ground segment is transmitted to JSC and GSFC simultaneously . 
Data to the TDRSS ground segment from GSFC and JSC will be transmi 
via the MDM only. In addition, NASCOM provides TV, voice, TTY, and 
systems control circuits* 



NASCOM operates within the STDN in accordance with a schedule 
provided by the NCC and reconfigures equipment in response to direction 
from the NCC. NASCOM provides the NCC with the status of services an 
also provides a postevent performance summary. 

NASCOM will also provide multiple 56-kb/sec circuits or a 224- 
kb/sec circuit among the GN, GSFC, JSC, and the NCC. Additional 
circuits will be provided to support the communication interfaces among 
the NCC, GSFC, DOD control centers, and other NASA control centers. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NASCOM SCHEDULE ACCEPT/REJECT 

NASCOM DESTINATION : NCC 

90/03 

1 FREQUENCY : 

Used to notify the NCCDS if an event can be 
supported or not. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


NASCOM RECONFIGURATION ACCEPT/REJECT 
NASCOM DESTINATION : NCC 

90/07 

1 FREQUENCY : 


Reports to the NCC the acceptance os rejection of 
an Nascom Reconfiguration request. 


DESCRIPTION 



message name 

ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


NAS COM 
NAS COM 
90/08 
1 


STREAM STATUS REPORT 
DESTINATION 

FREQUENCY 


NCC 


used to report changes in NASCOM data stream 
status . 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


NASCOM COMMUNICATIONS STATUS REPORT 
NASCOM DESTINATION 


90/09 

1 


FREQUENCY 


Used to report changes in 


NASCOM equipment status. 


MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NASCOM 

NASCOM 

90/10 

1 


POSTEVENT REPORT 

DESTINATION 

FREQUENCY 


NCC 


Used to report the performance of every data 
stream in the event. 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


acknowledgement 


NCC 


destination 


03/14 

1 


FREQUENCY 


NAS COM 


sent upon reception of a complete message 
requiring an acknowledgement. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


NAS COM EVENT SCHEDULE 


NCC 

90/01 

1 


destination 


FREQUENCY 


NAS COM 


GROUP 

description 


.p scheduled services which 

invowfdatTTlow by sending a NES for each event. 


message name 

ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

description 


NAS COM EVENT CANCEL 


NCC 


DESTINATION 


90/02 

1 


FREQUENCY 


NASCOM 


Notifies Nascom that a pending or active event is 
canceled. 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


NASCOM EVENT SCHEDULE UPDATE 


NCC 

90/04 


DESTINATION 


FREQUENCY 


NASCOM 


Used to notify NCCDS if 
or not. 


an event can be supported 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NASCOM EVENT 
NCC 
90/05 
1 


SCHEDULE EMERGENCY 
DESTINATION 

FREQUENCY 


NASCOM 


Schedull. N NCC°will automations 6 specified 

whenever • 1 autoinat ically send NESU 

45minutes". hGre 1S 3 SChedule greater than 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


NASCOM RECONFIGURATION REQUEST 


NCC 

90/06 


DESTINATION 


FREQUENCY 


NASCOM 


Used to provide 
addition within 
time. 


ergency scheduling changes 
45 minutes of the event start 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


COMMUNICATION 

NCC 

91/03 

1 


TEST MESSAGE 
DESTINATION 

FREQUENCY 


NAS COM 


Used to verify the existence of an operational 
communication link. 


3.4 


EXTERNAL MESSAGES BETWEEN NCC AND NGT 


. , 4-V10 intprface between the N AS COM/ c citation carrier 

The NGT provides schedule messages based upon 

and the TDRSS services. schedules and allocates 

user requests . The NGT ScheduUng SYStem lNSSI^scheduie^a faack 

selected NGT resources based on these ” e ® mess) will control and 
to the NCC. The NGT Control and ^tus System (NCb > monitoring results 

and f s?atSs t «ports e to 1 the NCC . The NCC uses data monitoring results for 
fault isolation and TDRSS data accountability. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ACKNOWLEDGEMENT 


NGT 


DESTINATION 


03/60 

1 


FREQUENCY 


NCC 


Sent upon the reception of a complete message 
requiring an acknowledgement. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ngt schedule 

NGT 

86/51 

1 


SYSTEM-SCHEDULE STATUS 
DESTINATION : 


FREQUENCY 


NCC 


NSS Schedule Status messages are transmitted by 
the NGT to the NCC in response to NSS Add and 
Delete messages. Additional NSS Schedule Status 
messages are transmitted as necessary to reflect 
the NGT capability to support a schedule event. 


MESSAGE NAME 


NGT SCHEDULING SYSTEM- RECONFIGURATION ACC/REJECT 


ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NGT 

86/54 

1 


DESTINATION : NCC 


FREQUENCY 


NSS Reconfiguration Accept/Reject messages are 
transmitted from NGT to NCC in response to a NGT 
Service Reconfiguration Request. These messages 
indicate that the NGT has accepted or rejected the 
referenced reconfiguration request and if 
rejected, the reason for rejection. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


FAULT ISOLATION 
NGT 
88/03 
11 


& MONITORING SYSTEM REPORTS 
DESTINATION : NCC 

FREQUENCY : 5 


FIMS messages are used to transmit FIMS Data 
quality information, collected from the channels 
monitored, to the NCC. 


DESCRIPTION 


MESSAGE NAME 

• 

• 

ADMINISTRATIVE 

MESSAGE 


ORIGINATION 

• 

• 

NGT 

destination : 

NCC 

TYPE/CLASS 

• 

« 

88/54 



MESSAGE LENGTH 


1 

FREQUENCY : 


GROUP 





description 


Administrative message are used 
format alphanumeric text between 

to exchange free 
the NGT and NCC. 

MESSAGE NAME 


COMMUNICATION 

test message 


ORIGINATION 


NGT 

DESTINATION 

NCC 

TYPE/CLASS 


91/03 



MESSAGE LENGTH 


1 

FREQUENCY 

• 

GROUP 





description 

: 

This is used 
and the NCC . 

to verify connection between the NGT 
When acknowledgements to transmitted 



messages are 

not received. 


MESSAGE NAME 


ACKNOWLEDGEMENT 


ORIGINATION 


NCC 

DESTINATION 

: NGT 

TYPE/CLASS 


03/14 



MESSAGE LENGTH 


1 

FREQUENCY 

• 

GROUP 

: 





Sent upon the reception of a complete message 
requiring an acknowledgement. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NGT SCHEDULING SYSTEM - NORMAL 
NCC DESTINATION : NGT 

86/01 

1 FREQUENCY : 


NSS Event Add are used to transmit normal event 
from NCC to NGT when the event start time is more 
45 minutes in the future from the time the event 
was added to the NCC data base. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SCHEDULING SYSTEM - PREMIUM 
NCC DESTINATION : NGT 

86/02 

1 FREQUENCY : 


NSS Event Add message is used to transmit 
emergency schedule events from NCC to the NGT. A 
schedule event will be transmitted as an emergency 
event when the start time is less than 45 minutes 
but more than 5 minutes in the future from the 
time the event was added to the NCC data base. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NGT SCHEDULING SYSTEM - EVENT DELETION 
NCC DESTINATION : NGT 

86/03 

1 FREQUENCY : 


NSS Event Delete messages are used by the NCC to 
delete events from the NGT schedule. Event may be 
deleted up to and including the time that they are 
active. 



MESSAGE NAME 

NGT SCHEDULING SYSTEM - SERVICE 

RECONFIGURATION 

ORIGINATION : 

NCC 

DESTINATION 

NGT 

TYPE/CLASS : 

86/04 



MESSAGE LENGTH : 

1 

FREQUENCY 

• 

GROUP : 




DESCRIPTION : 

These messages are sent to the HOT as directives 
to change one or more data streams within 
ongoing service of a user event. The . . 

reconfiguration are specified on a service level 
and are 9 limited to changes to the TDRSS interface 
channel, data rate and data stream ID for each 
data with in the service. 

MESSAGE NAME : 

ADMINISTRATIVE 



ORIGINATION : 

NCC 

DESTINATION 

: NGT 

TYPE/CLASS : 

88/01 



MESSAGE LENGTH : 

1 

FREQUENCY 

» 

• 

GROUP * 




DESCRIPTION : 

Administrative messages are used to exchange free 
text format text from NCC to NGT. 

MESSAGE NAME : 

COMMUNICATION TEST 


ORIGINATION : 

NCC 

DESTINATION 

NGT 

TYPE/CLASS : 

91/03 



MESSAGE LENGTH : 

1 

FREQUENCY 

: 

GROUP : 




DESCRIPTION : 

Used to verify the existence 
communication link. 

of an operational 


3 . 5 EXTERNAL 

MESSAGES BETWEEN NCC AND POCC 


MESSAGE NAME 

: acknowledgement 


ORIGINATION 

: POCC 

DESTINATION : 

NCC 

TYPE/CLASS 




MESSAGE LENGTH 

: 1 

FREQUENCY : 


GROUP 




DESCRIPTION 

: Sent upon 

requiring 

^Acknowledgement ? C °" Plete ”’ eSSage 

MESSAGE NAME 

: COMMUNICATION TEST MESSAGE 


ORIGINATION 

: POCC 

DESTINATION : 

NCC 

TYPE/ CLASS 

: 91/03 


MESSAGE LENGTH 

: 1 

FREQUENCY 


GROUP 

: UPD 



DESCRIPTION 

: To test the 

NCCDS/User POCC communication link. 

MESSAGE NAME 

USER PERFORMANCE DATA REQUEST 


ORIGINATION 

: POCC 

DESTINATION : 

NCC 

TYPE/ CLASS 

: 92/04 


MESSAGE LENGTH 

: 1 

FREQUENCY ; 


GROUP 




description 

• Allows user* 

messages . 

to select or deactivate 

operation data 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


CONFIGURATION 

POCC 

93/01 

1 


CODE ID LIST 
DESTINATION 

FREQUENCY 


NCC 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


REACQUISITION REQUEST 
pocc DESTINATION 

98/03 

! FREQUENCY 


NCC 


GROUP 

DESCRIPTION 


GCMR 

Provides the user the capability to request a 
service compatible link reacquisition procedure. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


USER RECONFIGURATION REQUEST 
POCC DESTINATION 

98/04 

1 FREQUENCY 


NCC 


GCMR 

Provides the user the capability to request a 
reconfiguration of a specified service. 



MESSAGE NAME 


FORWARD LINK SWEEP REQUEST 


ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


POCC DESTINATION : NCC 

98/05 

1 FREQUENCY : 

GCMR 

Provides the user the capability to request a 
forward link sweep on the designated service. 


FORWARD LINK EIRP 

POCC DESTINATION : NCC 

98/06 

1 FREQUENCY : 

GCMR 

Provides the user the capability to request a 
reconfiguration of the SSA or KSA forward Link 
EIRP between normal and high power at TDRSS. 


EXPANDER USER FREQUENCY UNCERTAINTY REQUEST 
POCC DESTINATION : NCC 

98/07 

1 FREQUENCY : 

GCMR 

Provides the user the capability to expand the 
frequency uncertainty of the referenced ongoing 
return service. 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


DOPPLER COMPENSATION INHIBIT REQUEST 

POCC DESTINATION 

98/08 

1 FREQUENCY : 


NCC 


GCM 

Provides the user with the capability to request 
that Forward Link Doppler Compensation on specified 
link be inhibited. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SCHEDULE ADD REQUEST 

POCC DESTINATION : NCC 

99/10 

1 FREQUENCY : 


Used to request addition of an event to the 
schedule. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SCHEDULE DELETE REPORT 

POCC DESTINATION : NCC 

99/11 

1 FREQUENCY : 

Used by POCC to request deletion of an event from 
the schedule. 



MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ACKNOWLEDGEMENT 

NCC DESTINATION : POCC 


1 


FREQUENCY 


Sent upon the reception of a complete message 
requiring an acknowledgement. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


SN OPERATION DATA MESSAGE 
NCC DESTINATION 

91/03 

1 FREQUENCY 


POCC 


5 


GROUP 


OPM 


DESCRIPTION 


These messages are sent to the users when event 
support is ongoing. This is sent for a spacecraft 
or vehicle. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


Communication Test Message 

NCC DESTINATION : POCC 

91/03 

1 FREQUENCY : 

UPD 

Used to verify the communication link between the 
NCC and the POCC. 


MESSAGE NAME 


RETURN CHANNEL TIME DELAY DATA 


ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NCC DESTINATION : POCC 

92/52 

1 FREQUENCY : 


Used to transmit return channel time delay 
measurement data from NCC to user. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


RETURN CHANNEL TIME DELAY MEASUREMENT ME 
NCC DESTINATION : POCC 
92/62 

1 FREQUENCY : 


Used to transmit return channel time delay 
measurement data, range zero set, and range 
extractor unit measurements from the NCC to the 
POCCS . 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ACQUISITION FAILURE NOTIFICATION 

NCC DESTINATION : POCC 

92/63 

1 FREQUENCY : 


Notifies the user that return services did not 
occur due to the in ability of TDRSS to acquire 
user spacecraft. 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


TIME TRANSFER 

NCC DESTINATION : POCC 

92/66 

1 FREQUENCY : 

Used to transmit time transfer data from NCC to 
user. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


CONFIRM NORMAL SCHEDULE 

NCC DESTINATION : POCC 

94/01 

1 FREQUENCY : 


Generated for Forecast Week transmission or when 
nonemergency add executed during active time frame. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


CONFIRM PREMIUM SUPPORT SCHEDULE 

NCC DESTINATION : POCC 

94/02 

1 FREQUENCY : 


Generated when a schedule add is executed within 45 
minutes of event start time. 



MESSAGE NAME 


CONFIRM SIMULATION SCHEDULE 


ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NCC 

94/03 

1 


DESTINATION : POCC 


FREQUENCY 


Generated when simulation event is added an active 
time frame. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


GCM STATUS MESSAGE 

NCC DESTINATION : POCC 

98/01 

1 FREQUENCY : 

GCM 

Generated when GCMR receipt acknowledgement 
received or when Operation Message (OPM) status 
acceptance/ re j ection message SN site. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


GCM DISPOSITION 


NCC 


DESTINATION 


98/02 

1 


FREQUENCY 


POCC 


GCM 

Transmitted to the user to indicate whether or not 
an acknowledgement was received from WSGT. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


FREE TEXT MESSAGE 

NCC DESTINATION 

98/09 
1 


FREQUENCY 


POCC 


provides the capability 
text information between 


for the exchange of 
the NCC and secured 


free 


user. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SCHEDULE 

NCC 

99/01 

1 


DELETION NOTIFICATION 
DESTINATION 

FREQUENCY 


POCC 


Used to notify user of pending or final deletion 
of an event. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


SCHEDULE 

NCC 

99/02 

1 


ACCEPT/REJECT NOTIFICATION 
DESTINATION : 

FREQUENCY : 


POCC 


Sent to user in response to a schedule request. 
1404 , 2303 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


tdrs performance data 
NCC destination 


pocc 


99/03 


FREQUENCY 


TDRS Performance Data requested by user POCC for 
Schedule Event. No acknowledgement required. 


3.6 EXTERNAL MESSAGES BETWEEN NCC AND SDPF 

The SDPF is a user support facility data 

for earth-orbiting free-flyer P a Y , scoring and forwarding of 
input capture ^counting ^ommutat^n^a^l and provides 

re??ffIcat P fo°„ d r Ct c\libration and 

requirement^and^ unique S data products can be provided to a user under 
formalized agreements . 

in response to requests f refusers dlta 

destination for return servic ^ schedules. The SDPF prepares to 

receive 32 P p“ a^ tX-t^dat^^sea -hed^le^ # ^ 

E3SS the's^elements anflhe SDPF wili est to any reconf ^ration 
affecting the flow of return data to the SDPF 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ACKNOWLEDGEMENT 


SDPF 


03/14 


DESTINATION 


FREQUENCY 


Sent upon reception of a complete message requiring 
an acknowledgement. 


message name 

ORIGINATION 

type/class 
message length 
GROUP 

DESCRIPTION 


COMMUNICATION TEST 

sdpf destination 


91/03 

1 


FREQUENCY 


NCC 


Used to verify the existence of 

communication lm . 


an operational 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


acknowledgement 


NCC 


destination 


03/14 

1 


frequency 


SDPF 


Sent upon 
requiring 


reception of a complete message 

an acknowledgement. 


MESSAGE NAME 
ORIGINATION 

type/class 
message length 


NAS COM 
NCC 
90/01 
1 


EVENT SCHEDULE (NES) 
destination 

FREQUENCY 


SDPF 


GROUP 

description 


. ^ ,i i cr'heduled services 

contains information ^^Nls^esstge^s also 
.ch involve data f l° w * ^om resources needed to 
. NCCDS to schedule N add an event 

jport an SN event. Eacn 
the SDPF. 


MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 


NASCOM EVENT CANCEL (NEC) 
NCC DESTINATION 

90/02 
1 


FREQUENCY 


SDPF 


GROUP 

DESCRIPTION 


The NEC is used to cancel resource allocations 
previously scheduled by an NES or to cancel an 
active event. May be transmitted at any time 
nri or to or during an event. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NASCOM EVENT 
NCC 
90/04 
1 


SCHEDULE UPDATE 
DESTINATION 

FREQUENCY 


(NESU) 


SDPF 


NES sent greater than 45 minutes prior to event 
start time. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


NASCOM 

NCC 

90/05 

1 


EVENT SCHEDULE EMERGENCY 
DESTINATION 

FREQUENCY 


(NESE) 

: SDPF 


ESE is func tionall y identical to a ^tart^oT the 
xcept that the NESE is used when the start of the 

vent being scheduled is less than 45 minutes but a 
east 5 minutes away from the time that the 
essage is transmitted to Nascom CSS. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


NAS COM 
NCC 
90/06 
2 


RECONFIGURATION REQUEST 
DESTINATION 


FREQUENCY 


(NRR) 

: SDPF 


GROUP 

description 


GCM 

NRR is a around control message use to reconfigure 
data^ streams in an active service of an ongoing 
event ? slct. service within an event requires a 
separate NRR message. 


MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 


COMMUNICATION TEST 

DESTINATION 


NCC 

91/03 

1 


FREQUENCY 


SDPF 


GROUP 

description 


Used to verify the existence of an operational 
communication link. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

description 


SCHEDULE 

NCC 

99/02 

1 


RESULT MESSAGE 

DESTINATION 

FREQUENCY 


SDPF 


3.7 


external messages between ncc and wsgt 


WSGT operate in accordance wi in reS ponsef to NCC instructions, 
changes ongoing service Parameter * ler compensation information are 
TDRS antenna pointing angles . data- WSGT compute this 

determined from detailed spacecraft orbit data. # prede£lned force 

information by propaga in 9 force model are provided by the NCC. 

model . Both the state ™ . ° tat u^ and Jality o£ Ageing services and 

a?so ofe^lpment status Based on WSGT requests the NCC schedules 
WSGT Preventive Maintenance (PM) on a service basis. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 


ACKNOWLEDGEMENT 

WSGT 

03/06 

1 


DESTINATION 


FREQUENCY 


NCC 


GROUP 

DESCRIPTION 


OPM 

Sent upon the reception of a complete message 
requiring an acknowledgement. 


MESSAGE NAME : 

SHO STATUS 


ORIGINATION : 

WSGT 

DESTINATION 

TYPE/CLASS : 

03/51 


MESSAGE LENGTH : 

1 

FREQUENCY 

GROUP : 

SHO 



NCC 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


RETURN CHANNEL TIME 

WSG T DESTINATION 

03/52 
1 

OPM 


FREQUENCY 


NCC 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


PREVENTATIVE MAINTENANCE REQUEST 

WSGT DESTINATION : NCC 

03/53 

1 FREQUENCY : 

OPM 

Used to request TDRSS preventive maintenance. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SPECIAL REQUEST OR INFORMATION 

WSGT DESTINATION : NCC 

03/54 

1 FREQUENCY 

OPM 

Used to send free-form alphanumeric text. 


MESSAGE NAME 

• 

• 

TDRS MANEUVER 

REQUEST 


ORIGINATION 

• 

• 

WSGT 

DESTINATION 

: NCC 

TYPE/CLASS 

• 

03/59 



MESSAGE LENGTH 


1 

FREQUENCY 

* 

GROUP 


OPM 



DESCRIPTION 


Used to request approval for 
maneuver . 

a TDRS spacecraft 

MESSAGE NAME 


STATE VECTOR 

REJECTION 


ORIGINATION 

• 

WSGT 

DESTINATION 

: NCC 

TYPE/CLASS 

• 

• 

03/61 



MESSAGE LENGTH 


1 

FREQUENCY 


GROUP 


OPM 



DESCRIPTION 





MESSAGE NAME 


STATUS 



ORIGINATION 


WSGT 

DESTINATION 

: NCC 

TYPE/CLASS 


03/62 



MESSAGE LENGTH 


1 

FREQUENCY 

• 

GROUP 

: 

OPM 




DESCRIPTION 


Used to accept or reject OPM. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


ACQUISITION FAILURE NOTIFICATION 

WSGT DESTINATION : NCC 

03/63 

1 FREQUENCY : 

OPM 

Provides notification that TDRS cannot acquire a 
user spacecraft. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


COMMUNICATION TEST 

WSG t DESTINATION : NCC 

91/03 

1 FREQUENCY : 


Used to verify the existence of an operational 
communication link. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


EMERGENCY 

NCC 

02/01 

1 

SHO 


DESTINATION 


FREQUENCY 


WSGT 


Describe the services contained in an emergency 
SHO. 


DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


NORMAL 

NCC 

02/01 

1 

SHO 


DESTINATION : WSGT 


FREQUENCY 


Describes services contained in a normal SHO 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SIMULATION 

NCC 

02/03 

1 


DESTINATION 


FREQUENCY 


WSGT 


SHO 

Describes the services contained in a routine 
verification SHO. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


ROUTINE VERIFICATION 

NCC DESTINATION 

02/04 

1 FREQUENCY 

SHO 


WSGT 


Describes the service contained in a routine 
verification SHO. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/ CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


EMERGENCY ROUTINE VERIFICATION 
NCC DESTINATION 

02/05 
1 

SHO 


FREQUENCY 


(ERVS ) 

: WSGT 


Describes the services contained in a emergency 
routine verification SHO. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


SPECIAL REQUEST 
NCC 
03/01 
1 

OPM 


DESTINATION 


FREQUENCY 


WSGT 


Used to send free-form alpha-numeric text 
messages . 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


REACQUISITION REQUEST 

N CC DESTINATION : 

03/02 

1 FREQUENCY : 

OPM 

Used to initiate a reacquisition. 


WSGT 


DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


reconfiguration request 
NCC destination 

03/03 
1 


FREQUENCY 


WSGT 


OPM 

Used to reconfigure equipment supporting a user 
spacecraft . 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


FORWARD LINK 
NCC 
03/04 
1 

OPM 


SWEEP REQUEST 
DESTINATION 

FREQUENCY 


WSGT 


Used to initiate a sweep of forward link carrier 
frequency. 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 


FORWARD LINK EIRP RECONFIGURATION REQUEST 

DESTINATION : WSGT 


NCC 

03/06 

1 

OPM 


FREQUENCY 


Used to set the SSA or KSA EIRP to normal or high 
power. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


EXPANDER 

NCC 

03/07 

1 

OPM 


USER FREQUENCY UNCERTAINTY REQUEST 
DESTINATION : WSGT 

FREQUENCY : 


Used to increase receiver bandwidth for DG1, mode 2 
and DG2 . 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


USER ORBIT 
NCC 
03/09 
1 

OPM 


PREDICTION FORCE MODEL 
DESTINATION : 

FREQUENCY : 


WSGT 


Provides information that the TDRSS uses to 
propagate a stable vector. 


MESSAGE NAME 

2 

IMPROVED 

INTERRANGE VECTOR (IIRV) 

NOMINAL 

ORIGINATION 


NCC 

DESTINATION : 

WSGT 

TYPE/CLASS 


03/10 



MESSAGE LENGTH 


1 

FREQUENCY : 


GROUP 

: 

OPM 




DESCRIPTION 


MESSAGE NAME : 

acknowledgement 



ORIGINATION : 

NCC 


DESTINATION 

: WSGT 

TYPE/CLASS : 

03/14 




MESSAGE LENGTH : 

1 


FREQUENCY 

• 

GROUP : 

OPM 




DESCRIPTION : 

Sent upon 
requiring 

reception of a complete message 
an acknowledgement. 

MESSAGE NAME 

DELTA-T-ADJUSTMENT 


ORIGINATION : 

NCC 


DESTINATION 

: WSGT 

TYPE/CLASS : 

03/18 




MESSAGE LENGTH : 

1 


FREQUENCY 

: 

GROUP : 

OPM 




DESCRIPTION : 

Used to adjust 
state vectors. 

the epoch time 

parameter within 

MESSAGE NAME : 

PERIODIC 

SHO - 

NORMAL 


ORIGINATION : 

NCC 


DESTINATION 

: WSGT 

TYPE/CLASS : 

08/01 




MESSAGE LENGTH : 

1 


FREQUENCY 

: 

GROUP : 

SHO 




DESCRIPTION : 






MESSAGE NAME : PERIODIC SHO - SIMULATION 


ORIGINATION 

NCC 

TYPE/CLASS : 

08/03 

MESSAGE LENGTH : 

1 

GROUP : 

SHO 

DESCRIPTION : 



DESTINATION : WSGT 


FREQUENCY 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


PERIODIC SHO - 
NCC 
08/04 
1 

SHO 


ROUTINE VERIFICATION 
DESTINATION : 

FREQUENCY 


WSGT 


MESSAGE NAME 
ORIGINATION 
TYPE/CLASS 
MESSAGE LENGTH 
GROUP 

DESCRIPTION 


COMMUNICATION TEST 

NCC DESTINATION 

91/03 

1 FREQUENCY 

OPM 


WSGT 


Used to verify existence of an operational link 



4 . 


INTERNAL MESSAGES 


4.1 INTERNAL MESSAGES BETWEEN THE CCS AND ITS 

This interface is through the dual-rail Intersegment Local Area 
NPtwort (LAN) and can be on either rail of the LAN at any particular 
£Sh message passed between the ITS and CCS is uniquely 
identified by a combination of the NCC Function Type, the NCC Command 
Code / Function Code, and the NCC Command Subcode. ^ - s 

nc: e d to identify the segments involved. The ITS / CCS interface is 
identical to the ITS / SPS interface with the ex ception of the function 
1-vne The ITS can identify the sending segment (CCS or SPS) of 
message by its function type or the LAN connection on which the message 
was received because LAN connections are unique rather than share . 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 


Alert Additional Data Display 


DESTINATION 
FUNCTION CODE 


ITS 

5 


MESSAGE LENGTH 


var 


COMMAND SUBCODE : 


DESCRIPTION 


This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


Alert Message - Action Alert 

CC S DESTINATION : ITS 

5 FUNCTION CODE : 1 

COMMAND SUBCODE : 2 

One of three Alert Messages. These messages are 
sent to the IT for display in the Alert Areas of 
the screen. ‘ 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 


Alert Message- Information Alert 
CCS DESTINATION 

5 FUNCTION CODE 


ITS 

1 


MESSAGE LENGTH 
DESCRIPTION 


72 B 


COMMAND SUBCODE 


Alert messages are of three types [Information 
Alert, Action Alert, and 
Action-Alert-with-Associated Data] . Alert Messages 
are sent to the ITS for display in the Alert Areas 
of the screen. The primary screen has display 
areas for one Action Alert and two 
Information-Alerts. Action Alerts are queued on 
the SPS and Information Alerts are queued on the 
ITS. An Action Alert is replaced upon operator 
acknowledgement, and an Information Alert is 
replaced upon an Information Alert Timeout. 


MESSAGE NAME 


: Alert Messages 

Associated Data 


Action Alert With 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


CCS DESTINATION : ITS 

5 FUNCTION CODE : 1 

COMMAND SUBCODE : 3 

Same for other alert messages. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 


Background Display Request 
CCS DESTINATION 

5 FUNCTION CODE 


ITS 

25 


MESSAGE LENGTH 


var 


COMMAND SUBCODE : 


DESCRIPTION 


This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 



MESSAGE NAME 


: Coordinated Universal Time : 

Maintenance 


ORIGINATION : CCS 

FUNCTION TYPE : 5 


DESTINATION : ITS 

FUNCTION CODE : 40 


MESSAGE LENGTH 


16 


COMMAND SUBCODE : 2 


DESCRIPTION 


This message is sent periodically at whatever time 
interval is needed to keep the ITS UTC in sync with 
the real UTC. It is also sent at startup/ restart 
protocol in order to initialize UTC on the ITS. 


MESSAGE NAME 


: coordinated Universal Time 

Transition 


ORIGINATION : CCS 

FUNCTION TYPE : 5 


DESTINATION : ITS 

FUNCTION CODE : 40 


MESSAGE LENGTH 


16 B 


COMMAND SUBCODE : 1 


DESCRIPTION 


This message is sent by the CCS to all ITS nodes on 
the LAN. This will be done periodically at 
whatever time interval is needed to keep the ITS 
UTC in sync with the real UTC. It is also sent as 
part of the start up/restart protocol in order to 
initialize UTC on the ITS. 


MESSAGE NAME 


: Display Allowable Console Position 

Bit Map 


ORIGINATION : CCS 

FUNCTION TYPE : 5 

MESSAGE LENGTH : var 


DESTINATION : ITS 

FUNCTION CODE : 55 

COMMAND SUBCODE : 


DESCRIPTION 


This message specifies which logged on positions 
are allowed access to each display. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Display Data Return ASCII 

DESTINATION : ITS 

FUNCTION CODE : 27 

COMMAND SUBCODE : 

This message is sent to the CCS in response to data 
entries made in a display by the operator. 


CCS 

5 

var 


Display Data Return In Error ASCII 

DESTINATION : ITS 

FUNCTION CODE : 12 

COMMAND SUBCODE : 

This message is sent from the SPS to the ITS in 
response to an erroneous Display Data Return ASCII 
message. A bit in the error bit map is for the 
position of the prompt text on the screen as 
defined by the Display Template. 


CCS 

5 

var 


: Display Data Send ASCII For Consecutive 

Dynamic Update. 

DESTINATION : ITS 

FUNCTION CODE : 29 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


CCS 

5 

var 


MESSAGE NAME 


: Display Data Send ASCII For Initial 

Dynamic Display. 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


ccs DESTINATION : ITS 

5 FUNCTION CODE : 28 

var COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS . 


MESSAGE NAME 


: Display Data Send ASCII Message For New 

Display 


ORIGINATION : CCS 

FUNCTION TYPE : 5 


DESTINATION : ITS 

FUNCTION CODE : 3 


MESSAGE LENGTH 


var 


COMMAND SUBCODE : 


DESCRIPTION 


This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. For 
displays that need foreground data, the application 
will send that data as part of this message. The 
format of the data area of the message is dependent 
on the display number. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


Freeze Dynamic Updates Command 

DESTINATION : ITS 

FUNCTION CODE : 31 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


CCS 

5 

var 


DESCRIPTION 



MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Host IT Transition Control Message 
: - Down 

ccs DESTINATION : ITS 

5 FUNCTION CODE : 60 

12 B COMMAND SUBCODE : 2 

This message is sent as a result of the CCS 
receiving an "Open Success" indication, for an 
attempted LAN connection. The LAN Configuration 
Message specifies the function (prime or backup) of 
the LAN pathways from the CCS computer to/ from the 
ITS computer. 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Host IT Transition Control 

LAN Configuration Message. 

CCS DESTINATION : ITS 

5 FUNCTION CODE : 60 

12 b COMMAND SUBCODE : 1 

This message is sent as a result of the CCS 
receiving an "Open Success" indication for an 
attempted LAN connection. The LAN Configuration 
Message specifies the function (prime or backup) of 
the LAN pathways from the CCS computer to/ from the 
ITS computer. 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Host IT Transition Control 
: - Template Error 

CCS DESTINATION : ITS 

5 FUNCTION CODE : 60 

12 B COMMAND SUBCODE : 3 

This message is sent as a result of the CCS 
receiving an "Open Success" indication for an 
attempted LAN connection. The LAN Configuration 
Message specifies the function (prime or backup) of 
the LAN pathways from the CCS computer to/ from the 
ITS computer. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


Logoff Accepted 

CCS DESTINATION : ITS 

5 FUNCTION CODE : 41 

4 b COMMAND SUBCODE : 51 

This message is sent to the ITS as a result of a 
valid logoff by the console operator. 


Logon Accepted 



CCS 

DESTINATION : 

ITS 

5 

FUNCTION CODE : 

41 

1120 B 

COMMAND SUBCODE : 

50 


This message is sent to the ITS to signal a valid 
logon by the console operator. This message gives 
to the ITS the list of default rapid access 
displays for the positions. This message also 
sends to the ITS the password sequence number and a 
figure. 


Pending Alert Display 

DESTINATION : ITS 

FUNCTION CODE : 4 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


CCS 

5 

var 


DESCRIPTION 


MESSAGE NAME 


Service Message To It 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


CCS DESTINATION : ITS 

5 FUNCTION CODE : 2 

22 COMMAND SUBCODE : 0 

Service Messages are sent to the ITS for display in 
the Service Messasge Area of the screen. Numbered 
service messages are possible, but the sender may 
optionally send self-generated service text. 


Template Compare Command 

CCS DESTINATION : ITS 

5 FUNCTION CODE : 52 

COMMAND SUBCODE : 1 

This message contains the date of the last time the 
Template TIP files for the current configuration 
level were modified. The ITS is expected to compare 
this date with the date saved from the last time 
the Template Compare Request was received. If the 
dates do not match, the Display Directory Message 
will contain compilation time information 
associated with each displays template object 
currently stored on the ITS. 


Template Objects 

CCS DESTINATION : ITS 

5 FUNCTION CODE : 54 

COMMAND SUBCODE : 

A Template Object Message is sent to the ITS by the 
CCS for each display in the 11 display directory 
that is not consistent with the CCS Display 
Directory. This message contains the templates 
that are used by the ITS in generating displays and 
managing data entries. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Terminate Dynamic Display Command 

DESTINATION : ITS 

FUNCTION CODE : 30 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


CCS 

5 

var 


Unfreeze Dynamic Updates Command 

DESTINATION : ITS 

FUNCTION CODE : 32 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


CCS 

5 

var 


: Action Alert Acknowledgement from IT 

Operator 

: ITS DESTINATION : CCS 

: 5 FUNCTION CODE : 6 

: var COMMAND SUBCODE : 

: This message is sent by the ITS to the CCS to 

acknowledge a Display Data Send ASCII Message. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 

MESSAGE LENGTH 


Display Directory 

XTS DESTINATION : CCS 

5 FUNCTION CODE : 53 

var COMMAND SUBCODE : 

This message is sent by the ITS to the CCS in 
response to the ITS receiving a Template Compare 
Request message from the SPS. It contains a return 
status flag indicating if the Template 

Configuration Date as contained in the Template 
Compare Request matched on the ITS and CCS. If no 
match the display Directory Message contains a list 
of displays in use on the ITS and compilation 
dates for each display. The CCS uses these dates 
to determine if new Template Objects should be 
sent. 


IT Host Transition Control 
Deactivate 


ITS DESTINATION : CCS 

5 FUNCTION CODE : 61 

COMMAND SUBCODE : 2 

This message is sent by the ITS to the CCS in 
response to a request in the LAN Configuration 
Message. The Profile Message contains the logon 
state relative to each screen. 


IT Host Transition Control - Profile 


DESTINATION : CCS 

FUNCTION CODE : 61 

COMMAND SUBCODE : 1 


This message 
response to a 
Message. The 
state relative 


is sent by the ITS to the CCS in 
request in the LAN Configuration 
Profile Message contains the logon 
to each screen. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Loop 

Test Life Test 


ITS 

DESTINATION : 

CCS 

5 

FUNCTION CODE : 

62 

var 

COMMAND SUBCODE : 

1 

This message is sent in response 
the LAN Configuration Message. 

to a request 

Loop 

Test Life Test Response 


ITS 

DESTINATION : 

CCS 

5 

FUNCTION CODE : 

62 


COMMAND SUBCODE : 

2 


Pending Action Alerts Display Request 


ITS 

DESTINATION : 

CCS 

5 

FUNCTION CODE : 

22 


COMMAND SUBCODE : 


This message 

is sent by the ITS to 

the CCS 



4.2 INTERNAL MESSAGES BETWEEN THE SPS AND CCS 
MESSAGE NAME : Authorized User IDs/Passwords 

ORIGINATION : SPS DESTINATION : CCS 

FUNCTION TYPE ; 7 FUNCTION CODE • 20 

MESSAGE LENGTH : var COMMAND SUBCODE : 

DESCRIPTION : This message is sent to the CCS to transfer all 

authorized user IDs and Passwords. 


MESSAGE NAME 

• 

Current 

Site Status Response 


ORIGINATION 


SPS 

DESTINATION 

: CCS 

FUNCTION TYPE 


7 

FUNCTION CODE 

: 1 

MESSAGE LENGTH 


0 B 

COMMAND SUBCODE 

: 3 

DESCRIPTION 


This message is sent from the SPS 
communication synchronization, 
acknowledgement of the previous 
Message. 

to the CCS during 
It contains an 
CCS Site Status 

MESSAGE NAME 


Display 

Directory Message 


ORIGINATION 


SPS 

DESTINATION 

: CCS 

FUNCTION TYPE 


7 

FUNCTION CODE 

: 46 

MESSAGE LENGTH 

: 

var 

COMMAND SUBCODE 

: na 


DESCRIPTION : This message is sent to the CCS as a result of the 

SPS receiving a Display Directory Request Message 
from the CCS. It contains a list of displays in use 
on the SPS and compilation dates for each display. 
The CCS will use the compilation dates to determine 
which new template objects should be requested. 


MESSAGE NAME 


Event And Service Information Message 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


DESTINATION : CCS 

FUNCTION CODE : 30 

COMMAND SUBCODE : 

The detailed event portion of this message requires 
modifications to compensate for the change from the 
36 bit U1100 to the 32 bit VAX. 


SPS 

7 

var 


Event 

Termination Message 


From 

SSQ4 to EMQ8 


SPS 

DESTINATION : 

CCS 

7 

FUNCTION CODE : 

31 

44 B 

COMMAND SUBCODE : 

0 


This message from SSQ4 to EMQ8 signals the 
termination of an event. 


Service Parameter Message 

DESTINATION : CCS 

FUNCTION CODE : 24 

COMMAND SUBCODE : 

This message transfers service parameter data from 
the SPS to the CCS. If the parameter values for a 
given service type and parameter type do not change 
for subsequent spacecraft the verification method 
for the spacecraft will be set as "same". 


SPS 

7 

var 


MESSAGE NAME 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


SPS Application Routing Information 

DESTINATION : CCS 

FUNCTION CODE : 1 

COMMAND SUBCODE : 4 

This message is sent from the SPS to the CCS during 
communication synchronization. 


SPS 

7 

var 


SPS System Configuration 

SPS DESTINATION : CCS 

7 FUNCTION CODE : 1 

12 B COMMAND SUBCODE : 1 

This message is sent to the CCS during 
Communication synchronization. This message 

contains the SPS System Level (Operational, Test, 
Development), SPS Role Configuration (Prime, 
Backup) and SPS Software Execution Level, which 
specifies the data base to use. 


SPS System Parameter Transfer Message 

SPS DESTINATION : CCS 

7 FUNCTION CODE : 1 

0 B COMMAND SUBCODE : 2 

This message is sent from the SPS to the CCS during 
f-n mm nnir.at-.ion synchronization. It contains an 
acknowledgement to the previous CCS System 
Parameter Transfer Message. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


SPS-IT Logon/Logoff Status 

DESTINATION : CCS 

FUNCTION CODE : 1 

COMMAND SUBCODE : 5 

This message is sent to the CCS during 
communication synchronization. It contains all the 
It Logon/Logoff Status as SPS views it. 


SPS 

7 

var 


Static Data Transfer Message 

DESTINATION : CCS 

FUNCTION CODE : 23 

COMMAND SUBCODE : 

This message is sent by the SPS to the CCS to 
reguest transfer of static data to CCS. 


Template Compare Message 

SPS DESTINATION : CCS 

7 FUNCTION CODE : 45 

12 int COMMAND SUBCODE : 1 

This message contains the data of the last time the 
template TIP files for the current configuration 
level were modified. If this date does not match 
with other data at the CCS, the CCS sends a Display 
Directory Request to continue the synchronization 
process . 


SPS 

7 

var 



MESSAGE NAME 


Template Object Message 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME : 

ORIGINATION : 

FUNCTION TYPE : 

MESSAGE LENGTH 

DESCRIPTION : 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION : 


SPS 


DESTINATION : CCS 


FUNCTION CODE : 47 


var 


COMMAND SUBCODE : NA 


This message is sent by the SPS to the CCS for each 
display in the CCS display that is not current with 
the SPS Display Directory. It contains any one of 
the templates that are used by the CCS supporting 
ITS displays and display data entries. 


Valid SICs and Spacecraft Names 


SPS 

7 

DESTINATION : 

FUNCTION CODE : 

CCS 

21 

var 

COMMAND SUBCODE : 



These messages transfer valid SICs and Spacecraft 
names from the SPS to the CCS. 


Valid TDRS - ID 

SPS DESTINATION : CCS 

7 FUNCTION CODE : 22 

40 B COMMAND SUBCODE : 

This message transfers valid SICs and Spacecraft 
names from the SPS to the CCS. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


CCS Application Routing Information 

DESTINATION : SPS 

FUNCTION CODE : 1 

COMMAND SUBCODE : 4 

This message is sent from the CCS to the SPS during 
communication synchronization. It contains the CCS 
Application Routing Information. 


CCS System Configuration 

CCS DESTINATION : SPS 

6 FUNCTION CODE : 1 

12 COMMAND SUBCODE : 1 

This is the first message sent to the SPS during 
communication synchronization. This message 

contains the CCS System Level (Operational, Test, 
Development) and CCS Role Configuration (Prime, 
Backup) . 


CCS 

6 

var 


CCS System Parameters Transfer 

DESTINATION : SPS 

FUNCTION CODE : 1 

COMMAND SUBCODE : 2 

This message is sent from the CCS to the SPS during 
communication synchronization. It contains the CCS 
to SPS I am alive interval and the ITS connection 
addresses . 


CCS 

6 

var 


DESCRIPTION 


MESSAGE NAME 


CCS-IT Logon/Logoff Status 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


CCS 

DESTINATION : 

SPS 

6 

FUNCTION CODE : 

1 

var 

COMMAND SUBCODE : 

5 

This message is sent from the CCS to the. SPS during 
communication synchronization. It contains the ITS 
Logon/Logoff Status as the CCS views it. 

Current Site Table Transfer 


CCS 

DESTINATION : 

SPS 

6 

FUNCTION CODE : 

1 

var 

COMMAND SUBCODE : 

3 


This message is sent from CCS to the SPS during 
communication synchronization. It contains all the 
current site status. 


Display 

Directory Request Message 


CCS 

DESTINATION : 

SPS 

6 

FUNCTION CODE : 

46 

0 B 

COMMAND SUBCODE : 

NA 


This message is sent by the CCS to the SPS if the 
compilation dates for the templates in the two 
segments do not match. It signals SPS to return 
the Display Directory Message. 


DESCRIPTION 


MESSAGE NAME 
ORIGINATION 


Template Compare Request Message 

CCS DESTINATION : SPS 


FUNCTION TYPE : 6 

MESSAGE LENGTH : 0 B 


FUNCTION CODE : 45 

COMMAND SUBCODE : 1 


DESCRIPTION 


This message is sent from the CCS to the SPS at the 
beginning of the template synchronization process. 
It signals SPS to return the Template Compare 
Message containing the compilation dates for the 
templates on SPS. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 


Template 

Object Request 



CCS 

DESTINATION 

• 

SPS 

6 

FUNCTION CODE 

: 

47 


MESSAGE LENGTH 


var 


COMMAND SUBCODE : NA 


DESCRIPTION : This message is sent by the CCS to the SPS to 

request template objects for which the compilation 
dates do not match. The request contains the 
templates needed by the template number. 


4.3 INTERNAL MESSAGES BETWEEN THE SPS AND ITS 

This interface is through a Local Area Network (LAN) to which the 
SPS and each Intelligent terminal is connected. Each message passed 
between the ITS and the SPS are uniquely defined by a combination of the 
NCC Function Type, the NCC Command / Function Code, and the NCC Command 
Subcode . 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Alert Additional Data Display 

DESTINATION : ITS 

FUNCTION CODE : 5 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


SPS 

1 

var 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Alert Message -Action Alert With Data 
sps DESTINATION : ITS 

x FUNCTION CODE : 1 

7 2 b COMMAND SUBCODE : 3 

Same as Information Alert. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Alert Message To IT - Action Alert 


SPS 

1 

72 B 


DESTINATION : ITS 

FUNCTION CODE : 1 

COMMAND SUBCODE : 2 


Same as Information Alert. 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 


Alert Message to IT - Information Alert 


SPS 


DESTINATION 


ITS 


1 


FUNCTION CODE 


1 


MESSAGE LENGTH 


72 B 


COMMAND SUBCODE 


1 


DESCRIPTION 


Alert messages are of three types [Information 
Alert, Action Alert and Action Alert with 
Associated Data] . Alert Messages are sent to the 
ITS for display in the Alert Areas of the screen. 
The primary screen has display areas for one 
Action Alert and two Information Alerts. Action 
Alerts are gueued on the SPS and Information Alerts 
are queued on the ITS. An Action Alert is replaced 
upon operator acknowledgement, and an Information 
Alert is replaced upon an information Alert 
Timeout. 


MESSAGE NAME 


Background Display Request 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


SPS DESTINATION : ITS 

1 FUNCTION CODE : 25 

var COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


: Coordinated Universal Time : 

Maintenance 

; SPS DESTINATION : ITS 

. i FUNCTION CODE : 40 

; 16 B COMMAND SUBCODE : 2 

: This message is sent periodically at whatever time 

interval is needed to keep the ITS UTC in sync with 
the real UTC. It is also sent at startup/restart 
protocol in order to initialize UTC on the ITS. 


: Coordinated Universal Time : 

Transition 

: SPS DESTINATION : ITS 

: i FUNCTION CODE : 40 

: 16 B COMMAND SUBCODE : 2 

: This message is sent periodically to all ITS nodes 

on the LAN at whatever time interval is needed to 
keep the ITS UTC in sync with the real UTC. It is 
also sent at startup/ restart protocol in order to 
initialize UTC on the ITS. 


DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 

ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 


Display Allowable Console Posit Bit Map 

DESTINATION : ITS 

FUNCTION CODE : 55 

COMMAND SUBCODE : 

This message specifies which logged-on positions 
are allowed access to each display. 


SPS 

1 

var 


Display Data Return In Error ASCII 

SPS DESTINATION : ITS 

1 FUNCTION CODE : 12 

var COMMAND SUBCODE : 

This message is sent from the SPS to the ITS in 
response to an erroneous Display Data Return ASCII 
Message. A bit in the Error Bit Map is set for the 
position of the prompt text on the screen as 
defined by the display template. 


: Display Data Send ASCII for Consecutive 

Dynamic Update 

: SPS DESTINATION : ITS 

: 1 FUNCTION CODE : 29 

: var COMMAND SUBCODE : 

: This message is sent to the ITS to request that a 

display be sent to the screen of the ITS. 


DESCRIPTION 



MESSAGE NAME 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 

DESCRIPTION 


: Display Data Send ASCII-Initial Dynamic 

Display 

: SPS DESTINATION : ITS 

; i FUNCTION CODE : 28 

; var COMMAND SUBCODE : 

: This message is sent to the ITS to request that a 

display be sent to the screen of the ITS. For 
displays that need foreground data, the application 
will send that data as part of the message. Format 
of data for message is dependent on display number. 


Display Data Send-ASCII for new display 

DESTINATION : ITS 

FUNCTION CODE : 3 

COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. For 
displays that need foreground data, the application 
will send that data as part of this message. The 
format of the data area of the message is dependent 
on the display number. 


SPS 

1 

var 


Freeze Dynamic Updates Command 
SPS DESTINATION : IT 

1 FUNCTION CODE : 31 

Var COMMAND SUBCODE : 


This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 



MESSAGE NAME 


Host-IT Transition Control : Down 


ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


SPS 

1 

12 B 


DESTINATION : ITS 

FUNCTION CODE : 60 

COMMAND SUBCODE : 2 


MESSAGE NAME 


: Host-IT-Transition-Control LAN 

Configuration. 


ORIGINATION : SPS 

FUNCTION TYPE : 1 


DESTINATION 
FUNCTION CODE 


ITS 

60 


MESSAGE LENGTH 


12 B 


COMMAND SUBCODE : 1 


DESCRIPTION 


This message is sent as a result of the SPS 
receiving an "Open Success" indication for an 
attempted LAN connection. The LAN Configuration 
Message specifies the function (prime or backup) of 
the LAN pathways from the SPS computer to/from 
the ITS computer. 


MESSAGE NAME 

Error 

Host- 

IT-Transition-Control : Template 


ORIGINATION 

: 

SPS 

DESTINATION : 

ITS 

FUNCTION TYPE 

: 

1 

FUNCTION CODE : 

60 

MESSAGE LENGTH 

: 

12 B 

COMMAND SUBCODE : 

3 


DESCRIPTION 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Logoff Accepted 


SPS 

DESTINATION 

: ITS 

1 

FUNCTION CODE 

: 41 

4 B 

COMMAND SUBCODE 

: 51 

This message is 
valid logoff by 

sent to the ITS as a result 
the console operator. 

Logon Accept 



SPS 

DESTINATION 

: IT 

1 

FUNCTION CODE 

: 41 

1120 B 

COMMAND SUBCODE 

: 50 


This message is sent to the ITS to signal a valid 
logon by the console operator. This message gives 
to the ITS the list of default rapid access 
displays for the position. This message also sends 
to the ITS the password sequence number and the 
logon position that must be included in any profile 
message. 


Loop Test - 

Life Test Response 


SPS 

DESTINATION : 

IT 

1 

FUNCTION CODE : 

62 

var 

COMMAND SUBCODE : 

2 


This message is sent in response to a request in 
the LAN Configuration Message. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Loop Test : Life Test 

DESTINATION : ITS 

FUNCTION CODE : 62 

COMMAND SUBCODE : 1 

This message is sent in response to a request in 
the LAN Configuration Message. 


SPS 

1 

var 


Pending Alerts Display 

SPS DESTINATION : ITS 

1 FUNCTION CODE : 4 

var COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


Service Message To IT-Text Included 

SPS DESTINATION : ITS 

1 FUNCTION CODE : 2 

72 B COMMAND SUBCODE : 0 

Service Messages are sent to the ITS for display in 
the Service Message Area of the screen. Numbered 
service messages are possible, but the sender may 
optionally send self -generated service text. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Template Compare Command 

SPS DESTINATION : IT 

1 FUNCTION CODE : 52 

COMMAND SUBCODE : 1 

This message contains the date of the last time the 
Template TIP files for the current configuration 
level were modified. The ITS is expected to compare 
this date with the date saved from the last time 
the Template Compare Message was received. If the 
dates do not match, the Display Directory Message 
will contain compilation time information 
associated with each displays template currently 
stored on the ITS . 


Template Object 



SPS 

DESTINATION : 

ITS 

1 

FUNCTION CODE : 

54 

var 

COMMAND SUBCODE : 



A Template Object Message is sent to the ITS by the 
SPS for each display in the 11 display directory 
that is not consistent with the SPS Display 
Directory. This message contains the templates 
that are used by the IT in generating displays and 
managing data entries. 


Terminate Dynamic Display Commands 

SPS DESTINATION : ITS 

1 FUNCTION CODE : 30 

var COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME : 

ORIGINATION : 

FUNCTION TYPE : 
MESSAGE LENGTH : 

DESCRIPTION : 

MESSAGE NAME : 

ORIGINATION : 

FUNCTION TYPE : 
MESSAGE LENGTH : 
DESCRIPTION : 


Unfreeze Dynamic Updates Command 

SPS DESTINATION : ITS 

1 FUNCTION CODE : 32 

var COMMAND SUBCODE : 

This message is sent to the ITS to request that a 
display be sent to the screen of the ITS. 


Action Alert Acknowledgement 
From IT Operator 

ITS DESTINATION : SPS 

1 FUNCTION CODE : 6 

var COMMAND SUBCODE : 

This message is sent by the ITS to the SPS to 
acknowledge a Display Data Send ASCII Message. 


Display Data Return ASCII 

(ie operator data entries.) 

ITS DESTINATION : SPS 

1 FUNCTION CODE : 27 

var COMMAND SUBCODE : 

This message is sent to the SPS in response to data 
entries made in a display by the operator. It 
contains those entries plus information associated 
with particular entries for any non-mandatory data 
entry fields. In addition to being sent as a 
result of the operator indicating an end of data 
display this message may be saved by the ITS and 
sent again in response to the Prior Display and 
Rapid Access Retrieve Commands. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 

MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Display 

Directory 


ITS 

DESTINATION : 

SPS 

1 

FUNCTION CODE : 

53 

var 

COMMAND SUBCODE : 



This message is sent as a result of the ITS 
receiving a Template Compare Request Message. This 
message contains return status flag indicating if 
the date in the request matched on the SPS and ITS. 
If no match occurs this message contains a list of 
displays in use on the ITS and the compilation date 
for each display. The SPS will use the compilation 
dates to determine if new template objects should 
be sent to the ITS . 


IT-Host-Transition Control : Deactivate 


ITS 

DESTINATION : 

SPS 

1 

FUNCTION 

CODE : 

61 

var 

COMMAND 

SUBCODE : 

2 

Sent 

in response to 

a request 

in 


Configuration. 


IT-Host-Transition Control : Profile 


ITS 

DESTINATION : 

SPS 

1 

FUNCTION CODE : 

61 

var 

COMMAND SUBCODE : 

1 


This message is sent by the ITS to the SPS in 
response to a request in the LAN Configuration 
Message. The Profile Message contains the logon 
state relative to each screen. 



MESSAGE NAME 
ORIGINATION 
FUNCTION TYPE 
MESSAGE LENGTH 
DESCRIPTION 


Pending Action Alerts Display Request 

DESTINATION j sps 

1 FUNCTION CODE : 22 

Var COMMAND SUBCODE : 

This message is sent by the ITS to the SPS, 
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INTRODUCTION 


This paper presents a critique o. papers published in academic purnals relevant to 
network scheduling. Its purpose is to aid NASA personnel response, e for Tracking an 
Data Relay Satellite System (TDRSS) resource scheduling. Th.s paper is a step towar s 
the completion of Task 2.C.I. as outlined in "Engineering Technology for Networks 

Progress Report, January 1991 

A, this time, "schedulable resources for TDRSS are the links, bandwidth, and antennas 
for b0 ,h forward and return links for muKiple access (MA>, S-band single access (SSA). 
and K-band single access (KSA) services as well as tracking senrice using one-way 
doppler and MA and SA two-way range and doppler (Engineering Technology for 
Networks Progress Report, January 1991). ' Algorithms for scheduling recently 
discussed in academic journals are explored to determine ,f they can be app ,e ow 
the improvement of TDRSS resource scheduling. 

RECENT SCHEDULING SYSTEM HISTORY 


SCHEDULE REQUESTS 

Scheduling of TDRSS services is initiated when users submit a request for a 
tim e to the Network Control Center (NCQ. Users are composed o, NASA entities as 
well as other government agencies needing to communicate with both manne an 
unmanned space vehicles. Requests can e„her occur as or as « 

renuests- A specific request is a request submitted by an user requesting senrice or 

single transaction (or event) occurring 


is 


a request which a user submits for a 


within a specific time window. A generic request 
number of single transactions to be scheduled or, 


a repeating basis. Generic requests expand into two or more request instances. That is, 
request instances are the individual transactions which when summed make up a single 
generic request. 

SCHEDULER SELECTION CRITERIA 

In April of 1989, the conclusion of an attempt to find an automated resource scheduler 
was reached. Two systems - Jet Propulsion Laboratory's (JPl) RALPH scheduler 
implemented in TREES/FOREST and Code 522's ROSE scheduler implemented in 
Symbolics/LISP - were compared based on their abilities to "1) formulate generic 
requests which express the flexibility customers need, 2) [not] require customers tc 
specify information they're not interested in, 3) provide an easy-to-use operator interface, 
and 4) provide the functionality that operators need (TDRSS Scheduling Prototype- 
Status Report, April 19, 1989)." Of the two systems compared, the Resource Oriented 
Scheduling Engine (ROSE) was selected as the best alternative. 

RESOURCE ORIENTED SCHEDULING SYSTEM 

Currently, generic and specific requests are entered into ROSE to determine optimum 
schedules. At this time, ROSE creates schedules by using either maximum temporal 
c onstraints or m aximum peak resource utilization selection strategies. Maximum total 
resource utilization and minimum total resour ce utilization selection strategies can be 
added in the future if desired. ROSE also features the four request placement strategies: 

1) Quick, 2) Quick-Dynamic, 3) Compact, and 4) Best Resource Fit. When entering 

schedule requests, one single placement strategy is used to determine the optimum 
schedule. 
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ALTERNATIVE SCHEDULING ARCHITECTURES 

Three scheduling architectures were tested by NASA and implemented using a 
Symbolics 3640 LISP machine. They are: 1) Repeating Expand-Scheduling Cycles, 2) 
External Expansion, and 3) Internal Expansion. Internal expansion architecture is 
inherent within JPL's RALPH scheduler while the ROSE scheduler relies on the external 
expansion architecture. By October of 1989 it became apparent (through testing) that 
the external expansion architecture produced faster results, while the internal expansion 
architecture scheduled more requests. It was suggested at that time that both 
scheduling schemes should undergo more development and testing. It was 
hypothesized that the best scheme could be the combination of "...the global view of 
inter-request dependencies (provided by the external expansion architecture) with the 
ability to return to an earlier decision point in the scheduling process in an effort to 
schedule more requests (provided by the "backtracking" in the internal expansion 
architecture) (Scheduling Results Analysis Report for the NCC Prototype Testing, Task 
20-103)." By January of 1990, NASA, working under Task 20-103, had decided to 
develop a hybrid architecture combining the best attributes of the external expansion 
and the internal expansion architectures. 

NCC PRESCHEDULER 

In addition to ROSE, an NCC Prescheduler was proposed in June of 1989. The NCC 
Prescheduler was intended "to provide an intermediate generic scheduling capability in 
the NCC (NCC Prescheduler Proposal, 1989)." The idea was proposed because current 
methods of scheduling were thought to be inadequate for tasks required to be 
performed in the 1990's. The Prescheduler promised to: 1) Reduce the amount of 
manual conflict resolution, 2) make the schedule generation process more efficient, 3) 



reduce the amount of work 
to perform, and 4) improve 


individual Project Operations Control Centers (POCC, need 
pocc scheduling satisfaction and network resource 


utilization. 


SCHEDULING BY THE USER 

The scheduler uses this code to determine which tasks 
Each user has a pnonty co q( ^ „ be performed at a specific 

are more important than others. • for TDRSS services. Along with a priority , 

time is governed by the priority of users vying ^ ^ s(op timeS , and the 

users also can specify transmission rates, transn* ^ ^ transmit , nf0 rma.,cn 

duration of events. In addition, users may specif 

to their vehicle, receive information from their ve ic ' bu „hishasnot 

information to their vehicle. Arrival of user rogues, s may be 

been confirmed at this time. 


CURRENT LITERATURE REVIEW 


As stated in the prior section, an evaluation of current literature relative to scheduling will 
be presented to determine if any recent developments will be of help to NASA's NCC 
staff when trying to select and develop scheduling algorithms appropriate for the second 
generation NCC. 


SCHEDULING TO MINIMIZE COMPLETION TIME 


In the journal article, "Preemptive Scheduling to Minimize Maximum Completion Time on 
Uniform Processors with Memory Constraints," Charles Martel presents two algorithms 
which can be used to find schedules on m uniform processors (P-j, P2>- -’ P m) for n 
independent jobs (J-j , J 2 ,...,J n ). Assumptions made are that the processors are 
identical, and that jobs can be preempted and completed immediately or later on a"' 
processor. 

An O(nmlog^m) time algorithm is constructed to determine C max> "the earliest time by 
which all jobs can be completed (Martel, 1984)." The feasibility algorithm chosen by 
Martel uses a "...general model of parallel processors in which job Jj requires py units of 
time to be completed by processor Pj." "If x,j is the amount of time processor P, 
executes job Jj, then Jj is completed if and only if 

m 

W 1 -' 



Processors meeting this criterion are called unrelated processors. 



Advantages of this algorithm are that "any constraints that prohibit a job from being run 
on a machine can easily be incorporated (Martel, 1984)." Thus, Pjj is set to infinite when 
job Jj cannot run on Pj. 

The fact that jobs can be excluded from individual processors can play a role in the 
STDN since: 1) bandwidth is a function of a single channel, and 2) user spacecraft 
location will determine which TDRS(s) will be the processor(s). Thus, available channels 
can be viewed as processors, and user requests viewed as jobs. Further, TDRS location 
can be viewed as processors, and ability to use them will be determined by the user 
spacecraft location. 

It should be noted that Martel's approach does not include the use of priorities. If 
priorities can be incorporated as a selection criterion within this approach, then the 
approach may become a candidate for further exploration. 

APPROXIMATING THE MEAN TIME IN SYSTEM 


In the journal article, "Approximating the Mean Time in a Multiple-Server Queue that uses 
Threshold Scheduling," Nelson and Towsley present the study of a multiple-server (with 
servers having different service rates) system sharing a common queue. Assumptions in 
this paper are that there exists a set of N heterogeneous servers (P-j, P2 >---> p n) that 
serve a common queue with jobs arriving to the queue according to a time-invariant 
Poisson process with rate Lambda and are served in a first-come first-served (FCFS) 
basis. 

Priorities are excluded from Nelson and Towsley's scheduling schema. Analysis will 
result in an algorithm to approximate the expected response time of the system using a 



Markov process. Since priorities are excluded from computation (i,„ users are served 
in a FCFS bas,s) it would seem that this algorithm would have little use w„h,n 

scheduling activities. 


SIMULTANEOUS SERVICE FROM A SINGLE QUEUE 

ln the journal article, "On Waiting Times for a Queue in Which Customers Require 
Simultaneous Service from a Random Number of Servers," Andrew Se.la has presente 
a scheme in which the means and standard deviations of waiting ernes can be 
calculated. Assumptions are that: 1) arrival streams are Poisson distributed, service , 
requested simultaneously, servers are identical, and the congestion level, (Lambda) , , 

can be calculated. 

Seila's article may not be relevant to TORS operations since It relies oh Poisson arrival 
rates and identical severs. However, algorithms presented in the article may be used as 
a basis to approximate the number o, channeis required for STDN operations. This may 
be possible if users are segregated into classes by using bandwidth and typ 
transmission frequently used (i.e., MA, SSA. or KSA). If mis were done, it may be 
possible to determine user requirements individually 0*. view the STDN as be.ng 
composed of several entities, and determining sen/er levels for each of these entitle 

separately). 



CONCLUSIONS 


In order to further pursue the investigation of scheduling algorithms appropriate for the 
Space Network, investigators must first determine if: 1) Request arrivals are Poisson 
distributed, and 2) TDRS's can be treated as individual processors, and thus, excluded 
from some jobs. Finally, the physical characteristics of the current system must be 
determined. At this time the system should support 25 simultaneous users. Of these 25, 
NASA must determine which bandwidths, links, and antennas are being used. This will 
require some on site study by the investigators. 
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modelling of systems 


During the design and development of complicated systems, creators are faced with the 
need to understand system actions and performance prior to actual system 
implementation. In many cases, system creators will turn to modelling to help them 
understand how different design configurations will affect system performance. 

Modelling has two distinct forms: 1) Analytical, and 2) Simulation. Analytical modelling 
is based on mathematical equations with statistical underpinnings. Simulation 
iterative process (usually on a computer) in which a "model- is created which attempts to 
accurately emulate some variables in the actual system. Sample data must be entered 

into the process. 


COST CONSIDERATIONS 

Analytical modelling is usually less expensive than simulation since large amounts of 
computer time is not required. However, the development of analytical models may take 
longer than simulation models since analytic models can usually only describe a single 
specific system, i.e„ existing simulation models can be more easily adapted to describe 

new systems. 


analytic modelling for sn scheduling 

After a careful review of network scheduling performance literature, it has become 
apparent that no analytic models currently exist which will accurately describe SN 
resource scheduling performance ( Space Network Scheduling Algorithms Reviewed 


1991; Hoehn, 1991). However, because of the possibility of the lower cost of analytic 
modelling, and the fact that simulation scheduling algorithms will execute no faster than 
the actual system under study (resulting in slow feedback and high cost), we feel that 
analytic modelling should be investigated further to determine if it is still a viable 
alternative. Up to this time, a vast amount of research has been dedicated to developing 
analytical models for computer operating systems (COS). We feel that their is a close 
parallel between COS and the SN, and this similarity should be exploited if possible. 


SIMILARITIES BETWEEN THE SN AND COS 

Many COS's must distinguish between user priorities. That is, higher priorities will 
execute before any lower ones. To accomplish this, priorities are usually divided into 
discrete queues. In this way, the system polls queues to determine which jobs to 
execute first. The SN also uses priorities, so it may be possible to incorporate some 
COS knowledge towards the execution of jobs by priorities. 

Some performance measures which COS analytic models help measure are: 


1. Mean queue length 

2. Mean waiting time before service begins 

3. Mean time that a job spends in the system 

4. Utilization of processor capacity 

5. Relation between arrival and service distributions (Maekawa et. al„ 1987)" 

If a correct strategy to develop analytic models for SN resource scheduling is created 
a d followed, then it may be possible to use these performance measures to predict SN 



, Appropriately, what follows is an outline of a strategy to 


operation performance 
accomplish this purpose, 

proposed course of sn modelling research 

, investigate current COS relative to how they treat priorities as separate queues on a 
first-come-first-served basis. Consider TORS resources to be identical, an ,m 
requests specific (e.g„ do no. schedule relative to time windows). 

2 Determine how time windows can be incorporated into the queue by J 

mentioned above. This may mean the incorporation of a recursive approach 
initial resources are scheduled (i.e„ look-back capability). 


3. Consider TDRS resources needed by users 
require more than one satellite at a time). 

4. Consider chaining of satellites (i.e„ the user 
their vehicle). 


to be singular (i.e., the user will not 


requires more than one TDRS to reach 


5. Consider visibility limitations (i.e., times 
data). 


that satellites can receive and broadcast 



REFERENCES 


Hoehn, William K. Towards an Analytical Model for Space Network Scheduling 
Blacksburg, Virginia: Systems Engineering Design Laboratory at Virginia Polytechnic 
Institute and State University, 1991. 

Maekawa, M., A. Oldehoeft, and R. Oldehoeft Operating Systems . Menlo Park, 
California: The Benjamin/Cummings Publishing Company, Inc., 1987. 

SP9C6 Network Scheduling Algorithms Reviewed . Blacksburg, Virginia: Systems 
Engineering Design Laboratory at Virginia Polytechnic Institute and State University 
1991. 



SYSTEMS ENGINEERING REPORT 


Towards an Analytical Model 
for Space Network Scheduling 


William K. Hoehn 
ENGR-5104 



BACKGROUND 

SPACEFLIGHT TRACKING AND DATA NETWORK 

SPACE NETWORK 

NCC 

HISTORY 

TDRS DEPLOYMENT 

CHANGES IN THE NCC 

Automation 

New Directions 

SCOPE OF THIS REPORT 

SCHEDULING BACKGROUND 

NCC SCHEDULING PROCEDURES 

User Requests 

Prerequisite Information 

Prerequisite Information Defined 

Configuration Codes 

Prototype Events 

Spacecraft Priority List 

Spacecraft Visibility Information 

SCHEDULERS CURRENTLY UNDER STUDY 

SYSTEMS CONTEXT 

APPROACH 

EXPECTED OUTCOMES AND OUTPUTS 

ANALYTICAL MODELING OF SN SCHEDULING 

A SINGLE ANALYTICAL MODEL FOR SN SCHEDULING 

TWO ANALYTICAL MODELS TO DESCRIBE SN SCHEDULING 

DIFFICULTIES ASSOCIATED WITH 

Distribution of Arrival Rates 

The Assumption of Identical Processors 

Threshold Policies 

First-Come-First-Served Policy 

POSSIBILITIES FOR ANALYTICAL MODELING 

CONCLUSIONS 


....1 

....1 

....1 

....2 

....2 

2 

2 

2 

3 

3 

4 

4 

4 

4 

4 

5 

5 

5 

5 

6 

7 

7 

7 

9 

9 

9 

10 

10 


11 

11 

11 

12 



BACKGROUND 


SPACEFLIGHT TRACKING AND DATA NETWORK 

The Missions Operations and Data Systems Directorate (MO&DSD), located at Goddard 
Space Flight Center (GSFC) in Greenbelt, Maryland, "is responsible for program 
planning, development, and operation of the National Aeronautics and Space 
Administration's (NASA) near-Earth network of space and ground-based tracking and 
data communications facilities and systems (Network Division Systems Development 
Activities, 1989)." MO&DSD is responsible for the systems and services provided by the 
Spaceflight Tracking and Data Network (STDN). The STDN provides Tracking and Data 
Acquisition (T&DA) services to a diverse group of space flight projects. The MO&DSD is 
currently concerned with: 1) evolving space flight project requirements, 2) the need to 
reduce maintenance and operations costs, 3) the need to increase efficiency, 4) the 
replacement of obsolete systems, 5) the need to improve systems reliability and network 
availability, and 6) the expected increase in users vying for network services. 


SPACE NETWORK 


The Space Network (SN), a component of the STDN, "...was developed to provide a set 
of standard T&DA services to low-Earth orbiting satellites operating in the S- and Ku- 
band frequency ranges (Network Division Systems Development Activities, 1989)." The 
SN uses geostationary Tracking and Data Relay Satellites (TDRS) to provide coverage to 
low-Earth orbiting satellites, and manned spacecraft. 



NCC 


The Network Control Center (NCC) is responsible for scheduling resources available on 
the SN. Resources currently available include: 1) Ground Links, 2) Bandwidth, and 3) 
antennas. Antennas provide "...both forward and return links for multiple access (SSA), 
and K-band single access (KSA) services as well as tracking service using one-way 
doppler and MA and SA two-way range and doppler (Gill and Paul, 1991)." 


HISTORY 

TDRS DEPLOYMENT 


After deployment of the first TDRS in 1988, it became readily apparent that TDRS's would 
"...dramatically increase [the coverage available to low-Earth orbiting satellites] beyond 
that previously afforded through ground-based tracking stations (Networks Division 
Systems Development Activities, 1989)." In 1988, the MO&DSD determined that the 
STDN operations concepts should be modified to reflect the evolving demands expected 
to be placed on the network. The concepts were divided into six phases, with 
completion of the sixth to occur in 1 994. These changes, however, do not reflect 
changes to be made to the network when the space station comes on line in 1997. 

CHANGES IN THE NCC 
Automation 


In the 1970's, the NCC relied on UNIVAC computer systems. By the early 80's, a new 
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computer system (VAX) was selected and installed to provide real-time functions, while 
the UNIVAC's were retained to provide non-real-time functions. The changeover from 
UNIVAC's to VAX's took 18 months. During the changeover, it was determined that 
"UNIVAC applications and software was not suitable for the VAX environment, so the 
decision was made to convert the software to the VAX (Network Control Center Block II 

Project History Report, 1990)." 

New Directions 

At this time, the NCC is attempting to adhere to tasks specified under the STDN 
operations concepts. Tasks include developing a completely new system - Space 
Network Control Center-SNCC - by 1997 to meet expected demands resulting from the 
deployment of the space station. Currently, the NCC is attempting to: 1) develop top- 
level performance requirements for the SN, 2) gain knowledge and experience by 
simulating the existing SN, and 3) develop algorithms to schedule resources on the SN. 

SCOPE OF THIS REPORT 

TASK AREA 

This report will deal with only the task of developing analytic models to aid in the 
scheduling of resources on the SN. 
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SCHEDULING BACKGROUND 

NCC SCHEDULING PROCEDURES 
User Requests 

Scheduling of resources available on the SN is initiated when a Project Operations 
Control Center (POCC) submits a schedule request. The request consists of: 1) a time 
window, 2) a transmission rate, 3) the type of transmission, and 4) the number of events 
per day (Demonstration Plan for the NCC Generic Scheduler Task 29-103 Phase Two, 
1989). A time window is the earliest and latest time that transmission can begin. 
Transmission rates inform the NCC as to how many bits will be transferred per second. 
Transmission rates do not have to be the same in both directions (i.e., playback can be 
at a lower rate than the up-link rate). The type of transmission refers to the band 
requested. Bands available are: (SSA + KSA) = SA, and MA. There are 2 SA and 19 MA 
available per TDRS. The number of times per day refers to the number of identical 
events to occur per day. 

Prerequisite Information 

Prerequisite Information Defined 

In addition to the request submitted by the user, the NCC maintains a list of prerequisite 
information (Functional and Performance Requirements for the Network Control Center, 
1986). Prerequisite information includes "...normal levels and characteristics of a users 
service requirements and the visibility and network constraints on the service that can be 



, fid ^3 information includes configuration codes, prototype events, generic 
Zirements, spacecraft characteristics, the spacecraft priority list, spa = ec ^ " 
information, and SN resource availability (Functional and Performance Be u, remen 
the Network Control Center, 1986,." Configuration codes, prototype events, the 
spacecraft priority list, and spacecraft visibility information wtl, be further descn e 

below. 

Configuration Codes 

Tne NCC can either receive or store user reguested transfer rate and selected band. 
The package comprised of transfer rate and band is a configurat.on 


prototype Events 

A prototype event is comprised of user selected -...configuration codes and the,r J^ ve 
start times and durations (Functional and Pertormance Reguirements for the Network 

Control Center, 1986)." 


Spacecraft Priority List 


Priorities are assigned to users by NASA management by a 
need (with manned spacecraft having the highest prionty). 


ranking procedure based on 
Higher priorities take 


precedence over any priorities lower than them. 


Spacecraft Visibility Information 


The NCC is responsible for the storage of a "...set 


of information that specifies the 



periods when. ..[a user's] spacecraft will be visible to each of the operational TDRSs and 
within these periods the periods that are subject to sun interference in the user or TDRS 
antennas (Functional and Performance Requirements for the Network Control Center, 
1986)." An individual user can opt not to have this information stored if they wish. 


SCHEDULERS CURRENTLY UNDER STUDY 


Schedulers currently under study by NASA include the Resource Oriented Scheduling 
Engine, and Jet Propulsion Laboratory's (JPL) RALPH. RALPH relies on internal 
expanding architecture, and in testing was able to schedule more requests than ROSE, 
although it noteably slower than ROSE. ROSE relies on external expanding architecture, 
and is much faster than RALPH. ROSE, however, is not able to schedule as many 
requests as RALPH. Current investigations include hybrid approaches to combine the 
best attributes of the internal expanding and the external expanding architectures. Both 
of these schedulers move downwards through a sequence of instructions, and given 
both time windows, configuration codes, priorities, and visibilty, they both schedule 
resources for the SN. It should be noted that both RALPH and ROSE only consider one 
request at a time. RALPH'S internal expanding architecture enables the system to 
schedule more requests because it uses iteration to locate requests that can be moved 
to other resources so as to maximize efficiency of the SN. 
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SYSTEMS CONTEXT 

APPROACH 


This scheduling problem is a systems problem. This is because in order to determine 
the best scheduling algorithm, a systematic approach must be taken. This approach 
includes viewing the SN resources, and user requests along with the resulting schedule 
as a conserved system. That is, SN resources are finite, and as such, an increase in 
requests after all resources are deployed will result in an increase in delays and schedule 
length (Figure 1). 

EXPECTED OUTCOMES AND OUTPUTS 

The desired outcomes are to determine the optimum SN resource levels given user 
demands, and to increase user satisfaction. Outputs from the project should be: 1) 
increased utilization of SN resources, 2) decreased scheduling time, and 3) less time 
taken-up with scheduling conflict resolution. 
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SYSTEMS DYNAMICS MODEL 
FOR THE SPACE NETWORK 



BT=BAND TYPE (SA OR MA) 

LTR = LENGTH OF TRANSMISSION REQUEST 
P = PRIORITY 

W = TIME WINDOW REQUESTED 
ER = ERROR FIATE 
TR = TRANSMISSION RATE 
RQ = REQUEST QUEUE LENGTH 
S = SCHEDULE 

PQ = PROCESSING QUEUE LENGTH 

NT = NETWORK THROUGHPUT NOTE: Not all arrows show signs because 

NL = NETWORK LOAD I afn n0 [ SU re how the rates will affect 

CR = COMPLETED REQUESTS the modeL 

VI = VISIBILITY 


FIGURE 1 



9 


ANALYTICAL MODELING OF SN SCHEDULING 

A SINGLE ANALYTICAL MODEL FOR SN SCHEDULING 

Using systems dynamics, I would like to find an analytical model to describe the 
utilization of the SN's processors (i.e. , network load). Figure 1 shows the relationships 
between user's requests (composed of BT, LTR, P, W, ER, and TR) and completed 
requests. Since network resources (transmission rates and band types) and user 
requests (time windows and priorities) are not constants, the system is composed of 
heterogeneous elements. This renders the use of an analytical model at this level 
impossible. 

TWO ANALYTICAL MODELS TO DESCRIBE SN SCHEDULING 

Since analytic modelling at the top level is not possible, we may be able to divide the 
system into 2 separate systems according to band type. This division into two levels, 
however, still does not answer the question of how to handle user priorities and different 


transmission rates. 
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DIFFICULTIES ASSOCIATED WITH 
ANALYTICAL MODELING OF THE SN 

Distribution of Arrival Rates 

One problem to be considered is the arrival rate of user requests. Articles studied 
relating to scheduling consider user requests to be randomly distributed, and thus, 
consider them to be a Poisson process with arrival rate Lambda (Nelson and Towsley, 
1987) (Seila, 1984). It has not yet been shown that a Poisson process closely parallels 
arrivals of user requests at the NCC, and this assumption should not be used until more 
data is available. 

The Assumption of Identical Processors 

Another assumption discovered was that processors could be considered identical, and 
jobs terminated on one processor and resumed on another processor either 
immediately or at a later time (Martel, 1984). In the case of the SN, this would be an 
incorrect assumption since TDRS's (viewed as the processors) cannot provide identical 
service because they are constrained by their physical locations with respect to the 
curvature of the earth. That is, TDRS's must communicate with ground terminals, other 
TDRS's, and user vehicles. A single TDRS will usually be the only TDRS that can 
communicate directly with a user vehicle because of visibility limitations (i.e., line of site 
with user vehicle). Thus, TDRS's cannot be considered to be identical processors. 
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Threshold Policies 

Threshold policies schedule "...a job from the queue on an idle server Pj only if Tj is 

smaller than or equal to the threshold of any idle server and if the queue length is greater 
than or equal to Tj (Nelson and Towsley, 1987).“ Since threshold policies rely on 

homogeneity of processors and TDRSs are not homogeneous, the policy cannot be 

applied for the SN. 

First-Come-First-Served Policy 

First-come-first-served policies allow users requesting services first to have their job 
processed first (Seila, 1984). For the SN, FCFS policies can be used to resolve conflicts 
between users with identical priorities vying for services at the same time, but the policy 
cannot be used to settle disputes between users with differing priorities. Therefore, 

FCFS cannot be used as a primary method of distributing services to users in the SN. 

POSSIBILITIES FOR ANALYTICAL MODELING 

In the article, "Preemptive Scheduling to Minimize Maximum Completion Time on 
Uniform Processors with Memory Constraints," Martel discusses the possibility of 
prohibiting jobs from running on certain machines because of memory constraints. It 
may be possible to use this algorithm to exclude an individual TDRS from being 
considered as a candidate to execute a user request if visibility limitations are 
encountered. However, it should be noted that this algorithm does still not overcome the 
question of differing priorities. 


CONCLUSIONS 


Simulation of SN events may be a viable alternative, since it may not be possible to find a 
single analytical model for SN resources. Simulation of scheduling is already being done 
at GSFC to determine optimum scheduling architectures ( Demonstration Plan for the 
NCC Generic Scheduler Task 29-103 Phase Two). Because users are assigned 
priorities, the scheduling system cannot be modeled on a FCFS basis. The inability to 
schedule on a FCFS basis also contributes to the need for network simulation. The SN 
cannot be modeled using a threshold policy since a specific TDRS is usually required to 
complete a user request because of visibility constraints. Again, this limitation points to 
the need for simulation. 
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